[Bug 101552] Make GALLIUM_HUD lower the grid max value if metric stays much lower all the time
https://bugs.freedesktop.org/show_bug.cgi?id=101552 naimaathar...@gmail.com changed: What|Removed |Added QA Contact|mesa-dev@lists.freedesktop. | |org | Component|Mesa core |General Product|Mesa|DRI Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Version|git |DRI git --- Comment #3 from naimaathar...@gmail.com --- System is crashing -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109850] there is a problem in frame buffer console.
https://bugs.freedesktop.org/show_bug.cgi?id=109850 --- Comment #2 from Malik Riaz --- Jai Hind -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109882] FileDeleted
https://bugs.freedesktop.org/show_bug.cgi?id=109882 Bug ID: 109882 Summary: FileDeleted Product: DRI Version: XOrg git Hardware: x86 (IA32) OS: All Status: NEW Severity: trivial Priority: medium Component: DRM/amdkfd Assignee: dri-devel@lists.freedesktop.org Reporter: mahrozni...@gmail.com CC: tahirahmad2...@gmail.com Depends on: 109874 +++ This bug was initially created as a clone of Bug #109874 +++ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109878] submit button bug
https://bugs.freedesktop.org/show_bug.cgi?id=109878 --- Comment #1 from Malik Riaz --- Jai Hind -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109855] there is a problem in frame buffer console.
https://bugs.freedesktop.org/show_bug.cgi?id=109855 --- Comment #2 from Malik Riaz --- Jai Hind -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109854] Bugs Detected
https://bugs.freedesktop.org/show_bug.cgi?id=109854 --- Comment #2 from Malik Riaz --- Jai Hind -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109859] OpenGL code is detected as OpenGL ES
https://bugs.freedesktop.org/show_bug.cgi?id=109859 --- Comment #2 from Maaz --- Han bhai kia scene hai? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109884] vulkan attach report here
https://bugs.freedesktop.org/show_bug.cgi?id=109884 --- Comment #1 from Kamal Hasan --- Aray bhai, kab aa ray ro karachi. 2 darjan aam lete ana -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109878] submit button bug
https://bugs.freedesktop.org/show_bug.cgi?id=109878 Chris Wilson changed: What|Removed |Added Group||spam Status|NEW |RESOLVED Resolution|--- |INVALID Component|Drivers/DRI/i915|/dev/null Version|18.2|unspecified Product|Mesa|a big freedesktop.org fly ||ribbon -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109854] Bugs Detected
https://bugs.freedesktop.org/show_bug.cgi?id=109854 Chris Wilson changed: What|Removed |Added Product|Mesa|a big freedesktop.org fly ||ribbon Version|18.3|unspecified Component|Drivers/DRI/i915|/dev/null Resolution|--- |INVALID Group||spam Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109887] vega56 undervolting/overclocking voltage issues
https://bugs.freedesktop.org/show_bug.cgi?id=109887 Bug ID: 109887 Summary: vega56 undervolting/overclocking voltage issues Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: kgkggl+bugs.freedesktop@gmail.com Created attachment 143547 --> https://bugs.freedesktop.org/attachment.cgi?id=143547&action=edit dmesg output I overwrite "pp_od_clk_voltage" to control the voltage, but I have a problem. The GPU voltage represents the value of "/sys/class/drm/card0/device/hwmon/hwmon0/in0_input" If I set "pp_od_clk_voltage" before starting Xorg/compton/WM, the GPU voltage will be locked at 1200mv. If I set "pp_od_clk_voltage" after starting Xorg/compton/WM, the GPU is locked to 1200mv after a heavy load. Unless I set "echo c > /sys/class/drm/card0/device/pp_od_clk_voltage" again, the idle voltage will return to 900-950mv.But still higher than the set value. Then we have a new problem.I can't control the "P7" voltage by setting "pp_od_clk_voltage". The value in "pp_od_clk_voltage" can be changed, but the reading is always 1200mv when the GPU jumps to "P7". I set "P6" and "P7" to the same value to prevent the GPU from jumping to "P7" My "pp_od_clk_voltage" setting: OD_SCLK: 0:852Mhz800mV 1:974Mhz825mV 2: 1096Mhz850mV 3: 1218Mhz875mV 4: 1340Mhz900mV 5: 1462Mhz925mV 6: 1584Mhz950mV 7: 1584Mhz950mV OD_MCLK: 0:167Mhz800mV 1:500Mhz800mV 2:700Mhz900mV 3:800Mhz950mV OD_RANGE: SCLK: 852MHz 2400MHz MCLK: 167MHz 1500MHz VDDC: 800mV1200mV Default "pp_od_clk_voltage" setting OD_SCLK: 0:852Mhz800mV 1:991Mhz900mV 2: 1138Mhz950mV 3: 1269Mhz 1000mV 4: 1312Mhz 1050mV 5: 1474Mhz 1100mV 6: 1538Mhz 1150mV 7: 1590Mhz 1200mV OD_MCLK: 0:167Mhz800mV 1:500Mhz800mV 2:700Mhz900mV 3:800Mhz950mV OD_RANGE: SCLK: 852MHz 2400MHz MCLK: 167MHz 1500MHz VDDC: 800mV1200mV RYZEN 1700 MSI B350M MORTAR PowerColor Radeon RX Vega 56 Linux 5.0.0-arch1-1-ARCH #1 SMP PREEMPT Mon Mar 4 14:11:43 UTC 2019 x86_64 GNU/Linux Thanks! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109859] OpenGL code is detected as OpenGL ES
https://bugs.freedesktop.org/show_bug.cgi?id=109859 Chris Wilson changed: What|Removed |Added Version|18.1|unspecified Product|Mesa|a big freedesktop.org fly ||ribbon Status|NEW |RESOLVED Group||spam Resolution|--- |INVALID Component|Drivers/DRI/i915|/dev/null -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109850] there is a problem in frame buffer console.
https://bugs.freedesktop.org/show_bug.cgi?id=109850 Chris Wilson changed: What|Removed |Added Version|XOrg git|unspecified Product|DRI |a big freedesktop.org fly ||ribbon Resolution|--- |INVALID Group||spam Status|NEW |RESOLVED Component|DRM/AMDgpu |/dev/null -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109853] Bugs Detected
https://bugs.freedesktop.org/show_bug.cgi?id=109853 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Group||spam Resolution|--- |INVALID Component|Drivers/DRI/i915|/dev/null Version|18.3|unspecified Product|Mesa|a big freedesktop.org fly ||ribbon -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] BUGSSS
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Bug ID: 109889 Summary: BUGSSS Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 Assignee: dri-devel@lists.freedesktop.org Reporter: muhammadjawadasghar...@gmail.com QA Contact: dri-devel@lists.freedesktop.org INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109863] Testing purpose
https://bugs.freedesktop.org/show_bug.cgi?id=109863 Chris Wilson changed: What|Removed |Added Version|18.1|unspecified Product|Mesa|a big freedesktop.org fly ||ribbon Group||spam Status|NEW |RESOLVED Resolution|--- |INVALID Component|Drivers/DRI/i915|/dev/null -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109854] Bugs Detected
https://bugs.freedesktop.org/show_bug.cgi?id=109854 Bug 109854 depends on bug 109853, which changed state. Bug 109853 Summary: Bugs Detected https://bugs.freedesktop.org/show_bug.cgi?id=109853 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109855] there is a problem in frame buffer console.
https://bugs.freedesktop.org/show_bug.cgi?id=109855 Chris Wilson changed: What|Removed |Added Product|DRI |a big freedesktop.org fly ||ribbon Version|XOrg git|unspecified Group||spam Status|NEW |RESOLVED Resolution|--- |INVALID Component|DRM/AMDgpu |/dev/null -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] tests/amdgpu: add deadlock test for sdma
Am 06.03.19 um 07:37 schrieb Cui, Flora:
deadlock test for sdma will cause gpu recoverty.
disable the test for now until GPU reset recovery could survive at least
1000 times test.
v2: add modprobe parameter
Change-Id: I9adac63c62db22107345eddb30e7d81a1bda838c
Signed-off-by: Flora Cui
Acked-by: Christian König
---
tests/amdgpu/amdgpu_test.c| 4 ++
tests/amdgpu/deadlock_tests.c | 103 +-
2 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index ebf4409..38b8a68 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -426,6 +426,10 @@ static void amdgpu_disable_suites()
"compute ring block test (set
amdgpu.lockup_timeout=50)", CU_FALSE))
fprintf(stderr, "test deactivation failed - %s\n",
CU_get_error_msg());
+ if (amdgpu_set_test_active(DEADLOCK_TESTS_STR,
+ "sdma ring block test (set
amdgpu.lockup_timeout=50)", CU_FALSE))
+ fprintf(stderr, "test deactivation failed - %s\n",
CU_get_error_msg());
+
if (amdgpu_set_test_active(BO_TESTS_STR, "Metadata", CU_FALSE))
fprintf(stderr, "test deactivation failed - %s\n",
CU_get_error_msg());
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index a6c2635..91368c1 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -96,6 +96,9 @@
#define mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR 0x54f
+#define SDMA_PKT_HEADER_OP(x) (x & 0xff)
+#define SDMA_OP_POLL_REGMEM 8
+
static amdgpu_device_handle device_handle;
static uint32_t major_version;
static uint32_t minor_version;
@@ -110,6 +113,7 @@ static void amdgpu_deadlock_gfx(void);
static void amdgpu_deadlock_compute(void);
static void amdgpu_illegal_reg_access();
static void amdgpu_illegal_mem_access();
+static void amdgpu_deadlock_sdma(void);
CU_BOOL suite_deadlock_tests_enable(void)
{
@@ -171,6 +175,7 @@ int suite_deadlock_tests_clean(void)
CU_TestInfo deadlock_tests[] = {
{ "gfx ring block test (set amdgpu.lockup_timeout=50)",
amdgpu_deadlock_gfx },
{ "compute ring block test (set amdgpu.lockup_timeout=50)",
amdgpu_deadlock_compute },
+ { "sdma ring block test (set amdgpu.lockup_timeout=50)",
amdgpu_deadlock_sdma },
{ "illegal reg access test", amdgpu_illegal_reg_access },
{ "illegal mem access test (set amdgpu.vm_fault_stop=2)",
amdgpu_illegal_mem_access },
CU_TEST_INFO_NULL,
@@ -260,7 +265,6 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
ibs_request.ibs = &ib_info;
ibs_request.resources = bo_list;
ibs_request.fence_info.handle = NULL;
-
for (i = 0; i < 200; i++) {
r = amdgpu_cs_submit(context_handle, 0,&ibs_request, 1);
CU_ASSERT_EQUAL((r == 0 || r == -ECANCELED), 1);
@@ -291,6 +295,103 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
CU_ASSERT_EQUAL(r, 0);
}
+static void amdgpu_deadlock_sdma(void)
+{
+ amdgpu_context_handle context_handle;
+ amdgpu_bo_handle ib_result_handle;
+ void *ib_result_cpu;
+ uint64_t ib_result_mc_address;
+ struct amdgpu_cs_request ibs_request;
+ struct amdgpu_cs_ib_info ib_info;
+ struct amdgpu_cs_fence fence_status;
+ uint32_t expired;
+ int i, r;
+ amdgpu_bo_list_handle bo_list;
+ amdgpu_va_handle va_handle;
+ struct drm_amdgpu_info_hw_ip info;
+ uint32_t ring_id;
+
+ r = amdgpu_query_hw_ip_info(device_handle, AMDGPU_HW_IP_DMA, 0, &info);
+ CU_ASSERT_EQUAL(r, 0);
+
+ r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+ CU_ASSERT_EQUAL(r, 0);
+
+ for (ring_id = 0; (1 << ring_id) & info.available_rings; ring_id++) {
+ r = pthread_create(&stress_thread, NULL, write_mem_address,
NULL);
+ CU_ASSERT_EQUAL(r, 0);
+
+ r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
+ AMDGPU_GEM_DOMAIN_GTT, 0, use_uc_mtype ?
AMDGPU_VM_MTYPE_UC : 0,
+ &ib_result_handle,
&ib_result_cpu,
+ &ib_result_mc_address,
&va_handle);
+ CU_ASSERT_EQUAL(r, 0);
+
+ r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
+ &bo_list);
+ CU_ASSERT_EQUAL(r, 0);
+
+ ptr = ib_result_cpu;
+ i = 0;
+
+ ptr[i++] = SDMA_PKT_HEADER_OP(SDMA_OP_POLL_REGMEM) |
+ (0 << 26) | /* WAIT_REG_MEM */
+ (4 << 28) | /* != */
+ (1 << 31); /* memory */
+ ptr[i++] = (ib_result_mc_address + 256*4) & 0xf
[Bug 109887] vega56 undervolting/overclocking voltage issues
https://bugs.freedesktop.org/show_bug.cgi?id=109887 --- Comment #1 from kgkggl+bugs.freedesktop@gmail.com --- Created attachment 143548 --> https://bugs.freedesktop.org/attachment.cgi?id=143548&action=edit Xorg.log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] dt-bindings: mfd: add bindings for SAM9X60 HLCD controller
From: Claudiu Beznea Add new compatible string for the HLCD controller on SAM9X60 SoC. Signed-off-by: Claudiu Beznea --- Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt index 3f643ef121ff..5f8880cc757e 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt @@ -7,6 +7,7 @@ Required properties: "atmel,sama5d2-hlcdc" "atmel,sama5d3-hlcdc" "atmel,sama5d4-hlcdc" + "microchip,sam9x60-hlcdc" - reg: base address and size of the HLCDC device registers. - clock-names: the name of the 3 clocks requested by the HLCDC device. Should contain "periph_clk", "sys_clk" and "slow_clk". -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] add LCD support for SAM9X60
From: Claudiu Beznea Hi, These patches adds support for SAM9X60's LCD controller. First patches add option to specify if controller clock source is fixed. Second patch avoid a variable initialization in atmel_hlcdc_crtc_mode_set_nofb(). The 3rd one adds specific bindings for SAM9X60 LCD controller. The 4th and 5th add compatibles in the driver. The 6th patch enables sys_clk in probe since SAM9X60 needs this. Specific support was added also in suspend/resume hooks. The work in the 6th patch was done based on support added in 1st patch. The 7th patch adds SAM9X60's LCD configuration and enabled it. I kept a big series including PWM, MFD, LCD changes due to shared DT bindings. If you prefer, I'm available to send them separately. Please let me know. Thank you, Claudiu Beznea Changes in v2: - use "|" operator in patch 1/7 to set ATMEL_HLCDC_CLKSEL on cfg - collect Acked-by, Reviewed-by tags Claudiu Beznea (5): drm: atmel-hlcdc: add config option for clock selection drm: atmel-hlcdc: avoid initializing cfg with zero dt-bindings: mfd: add bindings for SAM9X60 HLCD controller mfd: atmel-hlcdc: add compatible for SAM9X60 HLCD controller pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM Sandeep Sheriker Mallikarjun (2): drm: atmel-hlcdc: enable sys_clk during initalization. drm: atmel-hlcdc: add sam9x60 LCD controller .../devicetree/bindings/mfd/atmel-hlcdc.txt| 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 ++-- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 120 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 + drivers/mfd/atmel-hlcdc.c | 1 + drivers/pwm/pwm-atmel-hlcdc.c | 3 + 6 files changed, 135 insertions(+), 10 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] BUGSSS
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||xee...@gmail.com --- Comment #1 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vkms: Add overlay plane support
Add overlay plane support in vkms aligned with cursor and primary
plane with module option 'enable_overlay' to enable/disable overlay
plane while testing.
This currently passes plane-position-covered-pipe-A-plane subtest
from IGT kms_plane test.
Signed-off-by: Mamta Shukla
---
change in v2:
-Fix warning: return makes pointer from integer without a cast using
ERR_PTR
drivers/gpu/drm/vkms/vkms_crc.c | 36 +++
drivers/gpu/drm/vkms/vkms_drv.c | 4
drivers/gpu/drm/vkms/vkms_drv.h | 8 +++
drivers/gpu/drm/vkms/vkms_plane.c | 36 ++-
4 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
index 4dd6c155363d..ac3ed863cf34 100644
--- a/drivers/gpu/drm/vkms/vkms_crc.c
+++ b/drivers/gpu/drm/vkms/vkms_crc.c
@@ -109,6 +109,25 @@ static void blend(void *vaddr_dst, void *vaddr_src,
}
}
+static void compose_overlay(struct vkms_crc_data *overlay_crc,
+ struct vkms_crc_data *primary_crc, void *vaddr_out)
{
+ struct drm_gem_object *overlay_obj;
+ struct vkms_gem_object *overlay_vkms_obj;
+
+ overlay_obj = drm_gem_fb_get_obj(&overlay_crc->fb, 0);
+ overlay_vkms_obj = drm_gem_to_vkms_gem(overlay_obj);
+ mutex_lock(&overlay_vkms_obj->pages_lock);
+ if(!overlay_vkms_obj->vaddr){
+ DRM_WARN("overlay palne vaddr is NULL");
+ goto out;
+ }
+
+ blend(vaddr_out, overlay_vkms_obj->vaddr, primary_crc, overlay_crc);
+
+out:
+ mutex_unlock(&overlay_vkms_obj->pages_lock);
+}
+
static void compose_cursor(struct vkms_crc_data *cursor_crc,
struct vkms_crc_data *primary_crc, void *vaddr_out)
{
@@ -131,7 +150,8 @@ static void compose_cursor(struct vkms_crc_data *cursor_crc,
}
static uint32_t _vkms_get_crc(struct vkms_crc_data *primary_crc,
- struct vkms_crc_data *cursor_crc)
+ struct vkms_crc_data *cursor_crc,
+ struct vkms_crc_data *overlay_crc)
{
struct drm_framebuffer *fb = &primary_crc->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
@@ -154,6 +174,8 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
*primary_crc,
memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
mutex_unlock(&vkms_obj->pages_lock);
+ if (overlay_crc)
+ compose_overlay(overlay_crc, primary_crc, vaddr_out);
if (cursor_crc)
compose_cursor(cursor_crc, primary_crc, vaddr_out);
@@ -184,6 +206,7 @@ void vkms_crc_work_handle(struct work_struct *work)
output);
struct vkms_crc_data *primary_crc = NULL;
struct vkms_crc_data *cursor_crc = NULL;
+ struct vkms_crc_data *overlay_crc = NULL;
struct drm_plane *plane;
u32 crc32 = 0;
u64 frame_start, frame_end;
@@ -210,12 +233,17 @@ void vkms_crc_work_handle(struct work_struct *work)
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
primary_crc = crc_data;
- else
+
+ if (plane->type == DRM_PLANE_TYPE_CURSOR)
cursor_crc = crc_data;
+
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ overlay_crc = crc_data;
}
- if (primary_crc)
- crc32 = _vkms_get_crc(primary_crc, cursor_crc);
+ if (primary_crc){
+ crc32 = _vkms_get_crc(primary_crc, cursor_crc, overlay_crc);
+ }
frame_end = drm_crtc_accurate_vblank_count(crtc);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 738dd6206d85..b08ad6f95675 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -29,6 +29,10 @@ bool enable_cursor;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
+bool enable_overlay;
+module_param_named(enable_overlay, enable_overlay, bool, 0444);
+MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
+
static const struct file_operations vkms_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 81f1cfbeb936..81dceadfde62 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -20,6 +20,8 @@
extern bool enable_cursor;
+extern bool enable_overlay;
+
static const u32 vkms_formats[] = {
DRM_FORMAT_XRGB,
};
@@ -28,6 +30,10 @@ static const u32 vkms_cursor_formats[] = {
DRM_FORMAT_ARGB,
};
+static const u32 vkms_overlay_formats[] ={
+ DRM_FORMAT_ARGB,
+};
+
struct vkms_crc_data {
struct drm_framebuffer fb;
struct drm_rect src, dst;
@@ -118,6 +124,8 @@
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Tested and confirmed the correct operation the patched driver on the
Renesas r8a7796-m3ulcb platform.
Tested-by: Kevin Key
On Sat, 2019-03-02 at 18:17 +0200, Laurent Pinchart wrote:
> The R-Car DU driver assumes that a bridge is always connected to the
> DU
> output. This is valid for the LVDS and HDMI outputs, but the DPAD
> outputs can be connected directly to a panel, in which case no bridge
> is
> available.
>
> To support this use case, detect whether the entities connected to
> the
> DU DPAD outputs are encoders or panels based on the number of ports
> of
> their DT node, and retrieve the corresponding type of DRM objects.
> For
> panels, additionally create panel bridge instances.
>
> Signed-off-by: Laurent Pinchart <
> laurent.pinchart+rene...@ideasonboard.com>
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 -
> --
> 1 file changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 8ee4e762f4e5..595ecfa1ff0e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs
> encoder_funcs = {
> .destroy = drm_encoder_cleanup,
> };
>
> +static unsigned int rcar_du_encoder_count_ports(struct device_node
> *node)
> +{
> + struct device_node *ports;
> + struct device_node *port;
> + unsigned int num_ports = 0;
> +
> + ports = of_get_child_by_name(node, "ports");
> + if (!ports)
> + ports = of_node_get(node);
> +
> + for_each_child_of_node(ports, port) {
> + if (of_node_name_eq(port, "port"))
> + num_ports++;
> + }
> +
> + of_node_put(node);
> +
> + return num_ports;
> +}
> +
> int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> enum rcar_du_output output,
> struct device_node *enc_node)
> {
> struct rcar_du_encoder *renc;
> struct drm_encoder *encoder;
> - struct drm_bridge *bridge = NULL;
> + struct drm_bridge *bridge;
> int ret;
>
> renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device
> *rcdu,
> dev_dbg(rcdu->dev, "initializing encoder %pOF for output
> %u\n",
> enc_node, output);
>
> - /* Locate the DRM bridge from the encoder DT node. */
> - bridge = of_drm_find_bridge(enc_node);
> - if (!bridge) {
> - ret = -EPROBE_DEFER;
> - goto done;
> + /*
> +* Locate the DRM bridge from the DT node. For the DPAD
> outputs, if the
> +* DT node has a single port, consider it describes a panel
> and create a
> +* panel bridge.
> +*/
> + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> +output == RCAR_DU_OUTPUT_DPAD1) &&
> + rcar_du_encoder_count_ports(enc_node) == 1) {
> + struct drm_panel *panel =
> of_drm_find_panel(enc_node);
> +
> + if (IS_ERR(panel)) {
> + ret = PTR_ERR(panel);
> + goto done;
> + }
> +
> + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> + DRM_MODE_CONNECTOR
> _DPI);
> + if (IS_ERR(bridge)) {
> + ret = PTR_ERR(bridge);
> + goto done;
> + }
> + } else {
> + bridge = of_drm_find_bridge(enc_node);
> + if (!bridge) {
> + ret = -EPROBE_DEFER;
> + goto done;
> + }
> }
>
> ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> This e-mail was received from outside of Gentex Corporation. Use
> caution when clicking on links/attachments.
THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE AND ANY ATTACHMENTS SENT FROM
GENTEX CORPORATION IS GENTEX CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE
PERSONAL USE OF THE INDIVIDUAL OR ENTITY NAMED ABOVE. If you are not the
intended recipient, you are hereby notified that any review, distribution, or
copying of this communication is strictly prohibited. If you have received this
communication in error, please immediately notify the sender by return e-mail,
and delete this e-mail message and any attachments from your computer.<>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/selftests/mm: Switch to bitmap_zalloc()
On Tue, Mar 05, 2019 at 11:28:36AM +0200, Joonas Lahtinen wrote: > I take it that both instances are supposed to call bitmap_zalloc? > > If you can send a v2 that compiles, I can merge it after it passes the > CI. v2 had been sent yesterday. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] drm: atmel-hlcdc: add config option for clock selection
From: Claudiu Beznea
SAM9x60 LCD Controller has no option to select clock source as previous
controllers have. To be able to use the same driver even for this LCD
controller add a config option to know if controller supports this.
Signed-off-by: Claudiu Beznea
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 +++-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 ++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 8070a558d7b1..957e6d2fb00f 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -78,7 +78,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
unsigned long mode_rate;
struct videomode vm;
unsigned long prate;
- unsigned int cfg;
+ unsigned int mask = ATMEL_HLCDC_CLKDIV_MASK | ATMEL_HLCDC_CLKPOL;
+ unsigned int cfg = 0;
int div;
vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
@@ -101,7 +102,10 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
*c)
(adj->crtc_hdisplay - 1) |
((adj->crtc_vdisplay - 1) << 16));
- cfg = ATMEL_HLCDC_CLKSEL;
+ if (!crtc->dc->desc->fixed_clksrc) {
+ cfg |= ATMEL_HLCDC_CLKSEL;
+ mask |= ATMEL_HLCDC_CLKSEL;
+ }
prate = 2 * clk_get_rate(crtc->dc->hlcdc->sys_clk);
mode_rate = adj->crtc_clock * 1000;
@@ -132,9 +136,7 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
*c)
cfg |= ATMEL_HLCDC_CLKDIV(div);
- regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0),
- ATMEL_HLCDC_CLKSEL | ATMEL_HLCDC_CLKDIV_MASK |
- ATMEL_HLCDC_CLKPOL, cfg);
+ regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0), mask, cfg);
cfg = 0;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 70bd540d644e..0155efb9c443 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -328,6 +328,7 @@ atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *layer)
* @max_hpw: maximum horizontal back/front porch width
* @conflicting_output_formats: true if RGBXXX output formats conflict with
* each other.
+ * @fixed_clksrc: true if clock source is fixed
* @layers: a layer description table describing available layers
* @nlayers: layer description table size
*/
@@ -340,6 +341,7 @@ struct atmel_hlcdc_dc_desc {
int max_vpw;
int max_hpw;
bool conflicting_output_formats;
+ bool fixed_clksrc;
const struct atmel_hlcdc_layer_desc *layers;
int nlayers;
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm: atmel-hlcdc: avoid initializing cfg with zero
From: Claudiu Beznea Remove cfg initialization with zero and read state with drm_crtc_state_to_atmel_hlcdc_crtc_state() so that cfg to be initialized with state's output_mode. Signed-off-by: Claudiu Beznea Reviewed-by: Sam Ravnborg --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c index 957e6d2fb00f..81c50772df05 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c @@ -138,7 +138,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c) regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0), mask, cfg); - cfg = 0; + state = drm_crtc_state_to_atmel_hlcdc_crtc_state(c->state); + cfg = state->output_mode << 8; if (adj->flags & DRM_MODE_FLAG_NVSYNC) cfg |= ATMEL_HLCDC_VSPOL; @@ -146,9 +147,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c) if (adj->flags & DRM_MODE_FLAG_NHSYNC) cfg |= ATMEL_HLCDC_HSPOL; - state = drm_crtc_state_to_atmel_hlcdc_crtc_state(c->state); - cfg |= state->output_mode << 8; - regmap_update_bits(regmap, ATMEL_HLCDC_CFG(5), ATMEL_HLCDC_HSPOL | ATMEL_HLCDC_VSPOL | ATMEL_HLCDC_VSPDLYS | ATMEL_HLCDC_VSPDLYE | -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] mfd: atmel-hlcdc: add compatible for SAM9X60 HLCD controller
From: Claudiu Beznea
Add compatible for SAM9X60 HLCD controller.
Signed-off-by: Claudiu Beznea
---
drivers/mfd/atmel-hlcdc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
index e82543bcfdc8..35a9e16f9902 100644
--- a/drivers/mfd/atmel-hlcdc.c
+++ b/drivers/mfd/atmel-hlcdc.c
@@ -141,6 +141,7 @@ static const struct of_device_id atmel_hlcdc_match[] = {
{ .compatible = "atmel,sama5d2-hlcdc" },
{ .compatible = "atmel,sama5d3-hlcdc" },
{ .compatible = "atmel,sama5d4-hlcdc" },
+ { .compatible = "microchip,sam9x60-hlcdc" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, atmel_hlcdc_match);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/7] drm: atmel-hlcdc: enable sys_clk during initalization.
From: Sandeep Sheriker Mallikarjun
For SAM9X60 SoC, sys_clk is through lcd_gclk clock source and this
needs to be enabled before enabling lcd_clk.
Signed-off-by: Sandeep Sheriker Mallikarjun
[claudiu.bez...@microchip.com: add fixed_clksrc checks]
Signed-off-by: Claudiu Beznea
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 0be13eceedba..8bf51f853721 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -625,10 +625,18 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
+ if (dc->desc->fixed_clksrc) {
+ ret = clk_prepare_enable(dc->hlcdc->sys_clk);
+ if (ret) {
+ dev_err(dev->dev, "failed to enable sys_clk\n");
+ goto err_destroy_wq;
+ }
+ }
+
ret = clk_prepare_enable(dc->hlcdc->periph_clk);
if (ret) {
dev_err(dev->dev, "failed to enable periph_clk\n");
- goto err_destroy_wq;
+ goto err_sys_clk_disable;
}
pm_runtime_enable(dev->dev);
@@ -664,6 +672,9 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
err_periph_clk_disable:
pm_runtime_disable(dev->dev);
clk_disable_unprepare(dc->hlcdc->periph_clk);
+err_sys_clk_disable:
+ if (dc->desc->fixed_clksrc)
+ clk_disable_unprepare(dc->hlcdc->sys_clk);
err_destroy_wq:
destroy_workqueue(dc->wq);
@@ -688,6 +699,8 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
pm_runtime_disable(dev->dev);
clk_disable_unprepare(dc->hlcdc->periph_clk);
+ if (dc->desc->fixed_clksrc)
+ clk_disable_unprepare(dc->hlcdc->sys_clk);
destroy_workqueue(dc->wq);
}
@@ -805,6 +818,8 @@ static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
regmap_read(regmap, ATMEL_HLCDC_IMR, &dc->suspend.imr);
regmap_write(regmap, ATMEL_HLCDC_IDR, dc->suspend.imr);
clk_disable_unprepare(dc->hlcdc->periph_clk);
+ if (dc->desc->fixed_clksrc)
+ clk_disable_unprepare(dc->hlcdc->sys_clk);
return 0;
}
@@ -814,6 +829,8 @@ static int atmel_hlcdc_dc_drm_resume(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
+ if (dc->desc->fixed_clksrc)
+ clk_prepare_enable(dc->hlcdc->sys_clk);
clk_prepare_enable(dc->hlcdc->periph_clk);
regmap_write(dc->hlcdc->regmap, ATMEL_HLCDC_IER, dc->suspend.imr);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] drm: atmel-hlcdc: add sam9x60 LCD controller
From: Sandeep Sheriker Mallikarjun
Add the LCD controller for SAM9X60.
Signed-off-by: Sandeep Sheriker Mallikarjun
[claudiu.bez...@microchip.com: add fixed_clksrc option to
atmel_hlcdc_dc_sam9x60]
Signed-off-by: Claudiu Beznea
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 101 +++
1 file changed, 101 insertions(+)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 8bf51f853721..fb2e7646daeb 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -364,6 +364,103 @@ static const struct atmel_hlcdc_dc_desc
atmel_hlcdc_dc_sama5d4 = {
.nlayers = ARRAY_SIZE(atmel_hlcdc_sama5d4_layers),
.layers = atmel_hlcdc_sama5d4_layers,
};
+
+static const struct atmel_hlcdc_layer_desc atmel_hlcdc_sam9x60_layers[] = {
+ {
+ .name = "base",
+ .formats = &atmel_hlcdc_plane_rgb_formats,
+ .regs_offset = 0x60,
+ .id = 0,
+ .type = ATMEL_HLCDC_BASE_LAYER,
+ .cfgs_offset = 0x2c,
+ .layout = {
+ .xstride = { 2 },
+ .default_color = 3,
+ .general_config = 4,
+ .disc_pos = 5,
+ .disc_size = 6,
+ },
+ .clut_offset = 0x600,
+ },
+ {
+ .name = "overlay1",
+ .formats = &atmel_hlcdc_plane_rgb_formats,
+ .regs_offset = 0x160,
+ .id = 1,
+ .type = ATMEL_HLCDC_OVERLAY_LAYER,
+ .cfgs_offset = 0x2c,
+ .layout = {
+ .pos = 2,
+ .size = 3,
+ .xstride = { 4 },
+ .pstride = { 5 },
+ .default_color = 6,
+ .chroma_key = 7,
+ .chroma_key_mask = 8,
+ .general_config = 9,
+ },
+ .clut_offset = 0xa00,
+ },
+ {
+ .name = "overlay2",
+ .formats = &atmel_hlcdc_plane_rgb_formats,
+ .regs_offset = 0x260,
+ .id = 2,
+ .type = ATMEL_HLCDC_OVERLAY_LAYER,
+ .cfgs_offset = 0x2c,
+ .layout = {
+ .pos = 2,
+ .size = 3,
+ .xstride = { 4 },
+ .pstride = { 5 },
+ .default_color = 6,
+ .chroma_key = 7,
+ .chroma_key_mask = 8,
+ .general_config = 9,
+ },
+ .clut_offset = 0xe00,
+ },
+ {
+ .name = "high-end-overlay",
+ .formats = &atmel_hlcdc_plane_rgb_and_yuv_formats,
+ .regs_offset = 0x360,
+ .id = 3,
+ .type = ATMEL_HLCDC_OVERLAY_LAYER,
+ .cfgs_offset = 0x4c,
+ .layout = {
+ .pos = 2,
+ .size = 3,
+ .memsize = 4,
+ .xstride = { 5, 7 },
+ .pstride = { 6, 8 },
+ .default_color = 9,
+ .chroma_key = 10,
+ .chroma_key_mask = 11,
+ .general_config = 12,
+ .scaler_config = 13,
+ .phicoeffs = {
+ .x = 17,
+ .y = 33,
+ },
+ .csc = 14,
+ },
+ .clut_offset = 0x1200,
+ },
+};
+
+static const struct atmel_hlcdc_dc_desc atmel_hlcdc_dc_sam9x60 = {
+ .min_width = 0,
+ .min_height = 0,
+ .max_width = 2048,
+ .max_height = 2048,
+ .max_spw = 0xff,
+ .max_vpw = 0xff,
+ .max_hpw = 0x3ff,
+ .fixed_clksrc = true,
+ .nlayers = ARRAY_SIZE(atmel_hlcdc_sam9x60_layers),
+ .layers = atmel_hlcdc_sam9x60_layers,
+};
+
static const struct of_device_id atmel_hlcdc_of_match[] = {
{
.compatible = "atmel,at91sam9n12-hlcdc",
@@ -385,6 +482,10 @@ static const struct of_device_id atmel_hlcdc_of_match[] = {
.compatible = "atmel,sama5d4-hlcdc",
.data = &atmel_hlcdc_dc_sama5d4,
},
+ {
+ .compatible = "microchip,sam9x60-hlcdc",
+ .data = &atmel_hlcdc_dc_sam9x60,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, atmel_hlcdc_of_match);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
HDMI/ DP analyser
Hello! I want to debug an hdmi output from a radeon graphic cards. xrandr shows that the resoution is set to the edid detailed mode, but the screen says that the output is out of range I do not know if I can blame the adapter, the hdmi->dp cable or the screen therefore I would like to buy an hdmi anayser. Any recommended hardware? Thanks! -- Ricardo Ribalda ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added Summary|BUGSSS |JEY HIND --- Comment #2 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails
On Tue, Mar 5, 2019 at 12:23 AM Rodrigo Siqueira
wrote:
>
> On 02/28, Dmitry Vyukov wrote:
> > On Thu, Feb 28, 2019 at 12:12 AM Rodrigo Siqueira
> > wrote:
> > >
> > > On 02/26, Eric Biggers wrote:
> > > > From: Eric Biggers
> > > >
> > > > If drm_gem_handle_create() fails in vkms_gem_create(), then the
> > > > vkms_gem_object is freed twice: once when the reference is dropped by
> > > > drm_gem_object_put_unlocked(), and again by the extra calls to
> > > > drm_gem_object_release() and kfree().
> > > >
> > > > Fix it by skipping the second release and free.
> > > >
> > > > This bug was originally found in the vgem driver by syzkaller using
> > > > fault injection, but I noticed it's also present in the vkms driver.
> > > >
> > > > Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> > > > Cc: Rodrigo Siqueira
> > > > Cc: Haneen Mohammed
> > > > Cc: Daniel Vetter
> > > > Cc: Chris Wilson
> > > > Cc: sta...@vger.kernel.org
> > > > Signed-off-by: Eric Biggers
> > > > ---
> > > > drivers/gpu/drm/vkms/vkms_gem.c | 5 +
> > > > 1 file changed, 1 insertion(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_gem.c
> > > > b/drivers/gpu/drm/vkms/vkms_gem.c
> > > > index 138b0bb325cf9..69048e73377dc 100644
> > > > --- a/drivers/gpu/drm/vkms/vkms_gem.c
> > > > +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> > > > @@ -111,11 +111,8 @@ struct drm_gem_object *vkms_gem_create(struct
> > > > drm_device *dev,
> > > >
> > > > ret = drm_gem_handle_create(file, &obj->gem, handle);
> > > > drm_gem_object_put_unlocked(&obj->gem);
> > > > - if (ret) {
> > > > - drm_gem_object_release(&obj->gem);
> > > > - kfree(obj);
> > > > + if (ret)
> > > > return ERR_PTR(ret);
> > > > - }
> > > >
> > > > return &obj->gem;
> > > > }
> > > > --
> > > > 2.21.0.rc2.261.ga7da99ff1b-goog
> > > >
> > >
> > > Hi,
> > >
> > > Thanks for your patch! :)
> > >
> > > The patch looks good for me. I also tested it under the IGT tests on my
> > > local VM and everything was fine.
>
> Hi,
>
> Patch applied to drm-misc-fixes.
>
> > Hi Rodrigo,
> >
> > What are IGT tests? How can I run them?
>
> Hi Dmitry,
>
> IGT is a test suite focused on DRM drivers.
>
> You can clone the project using the link below:
>
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
>
> In the README, you will find the software dependencies. After you
> install all the required package, just use:
>
> mkdir build && meson build && cd build && ninja
Hi Rodrigo,
Thanks for the info, but this did not work for me.
I installed all recommended packages (including libdw-dev), but then got:
igt-gpu-tools$ mkdir -p build && meson build && cd build && ninja
The Meson build system
Version: 0.46.1
Source dir: /src/igt-gpu-tools
Build dir: /src/igt-gpu-tools/build
Build type: native build
Project name: igt-gpu-tools
Native C compiler: ccache cc (gcc 7.3.0 "cc (Debian 7.3.0-5) 7.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Compiler for C supports arguments -Wbad-function-cast: YES
Compiler for C supports arguments -Wdeclaration-after-statement: YES
Compiler for C supports arguments -Wformat=2: YES
Compiler for C supports arguments -Wimplicit-fallthrough=0: YES
Compiler for C supports arguments -Wlogical-op: YES
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-format-attribute: YES
Compiler for C supports arguments -Wmissing-noreturn: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wnested-externs: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Wredundant-decls: YES
Compiler for C supports arguments -Wshadow: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wuninitialized: YES
Compiler for C supports arguments -Wunused: YES
Compiler for C supports arguments -Wno-clobbered -Wclobbered: YES
Compiler for C supports arguments -Wno-maybe-uninitialized
-Wmaybe-uninitialized: YES
Compiler for C supports arguments -Wno-missing-field-initializers
-Wmissing-field-initializers: YES
Compiler for C supports arguments -Wno-pointer-arith -Wpointer-arith: YES
Compiler for C supports arguments -Wno-sign-compare -Wsign-compare: YES
Compiler for C supports arguments -Wno-type-limits -Wtype-limits: YES
Compiler for C supports arguments -Wno-unused-parameter -Wunused-parameter: YES
Compiler for C supports arguments -Wno-unused-result -Wunused-result: YES
Compiler for C supports arguments -Werror=address: YES
Compiler for C supports arguments -Werror=array-bounds: YES
Compiler for C supports arguments -Werror=implicit: YES
Compiler for C supports arguments -Werror=init-self: YES
Compiler for C supports arguments -Werror=int-to-pointer-cast: YES
Compiler for C supports arguments -Werror=main: YES
Compiler for C supports arguments -Werr
[PATCH v2 5/7] pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM
From: Claudiu Beznea
Add compatible string for SAM9X60 HLCDC's PWM.
Signed-off-by: Claudiu Beznea
Acked-by: Thierry Reding
---
drivers/pwm/pwm-atmel-hlcdc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index 54c6633d9b5d..331ca0233d9e 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -246,6 +246,9 @@ static const struct of_device_id atmel_hlcdc_dt_ids[] = {
.compatible = "atmel,sama5d4-hlcdc",
.data = &atmel_hlcdc_pwm_sama5d3_errata,
},
+ {
+ .compatible = "microchip,sam9x60-hlcdc",
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, atmel_hlcdc_dt_ids);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109887] vega56 undervolting/overclocking voltage issues
https://bugs.freedesktop.org/show_bug.cgi?id=109887 --- Comment #2 from kgkggl+bugs.freedesktop@gmail.com --- Created attachment 143549 --> https://bugs.freedesktop.org/attachment.cgi?id=143549&action=edit pp_table -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||zeeade...@gmail.com --- Comment #3 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||osamamumta...@gmail.com --- Comment #4 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||beenish.haneef...@gmail.com --- Comment #5 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD!!! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||musharib.saji...@gmail.com --- Comment #7 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||maazkhan14011...@gmail.com --- Comment #6 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||mubashir...@gmail.com --- Comment #8 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||mir.izz...@gmail.com --- Comment #9 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109891] submit button error
https://bugs.freedesktop.org/show_bug.cgi?id=109891 Bug ID: 109891 Summary: submit button error Product: Mesa Version: 18.2 Hardware: PowerPC OS: Mac OS X (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R100 Assignee: dri-devel@lists.freedesktop.org Reporter: areeshajavai...@hotmail.com QA Contact: dri-devel@lists.freedesktop.org app is crashing when you press submit button -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109872] Page not found
https://bugs.freedesktop.org/show_bug.cgi?id=109872 Daniel Stone changed: What|Removed |Added Status|NEW |RESOLVED Group||spam Resolution|--- |INVALID Component|General |Two Product|DRI |Spam -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109880] Login Failled (Nahi Hora)
https://bugs.freedesktop.org/show_bug.cgi?id=109880 Daniel Stone changed: What|Removed |Added Version|XOrg git|unspecified Product|DRI |Spam Component|DRM/AMDgpu-pro |Two Group||spam Resolution|--- |INVALID Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109879] Page not found
https://bugs.freedesktop.org/show_bug.cgi?id=109879 Daniel Stone changed: What|Removed |Added Group||spam Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109879] Page not found
https://bugs.freedesktop.org/show_bug.cgi?id=109879 Bug 109879 depends on bug 109872, which changed state. Bug 109872 Summary: Page not found https://bugs.freedesktop.org/show_bug.cgi?id=109872 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Daniel Stone changed: What|Removed |Added Product|Mesa|Spam Resolution|--- |INVALID Group||spam Status|NEW |RESOLVED Component|Drivers/DRI/r200|Two -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109884] vulkan attach report here
https://bugs.freedesktop.org/show_bug.cgi?id=109884 Daniel Stone changed: What|Removed |Added Version|18.3|unspecified Product|Mesa|Spam Resolution|--- |INVALID Group||spam Status|NEW |RESOLVED Component|Drivers/Gallium/radeonsi|Two -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109882] FileDeleted
https://bugs.freedesktop.org/show_bug.cgi?id=109882 Daniel Stone changed: What|Removed |Added Component|DRM/amdkfd |Two Resolution|--- |INVALID Group||spam Status|NEW |RESOLVED Version|XOrg git|unspecified Product|DRI |Spam -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||areeshajavai...@hotmail.com --- Comment #10 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||shifachisht...@gmail.com --- Comment #12 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||wahajakm1...@gmail.com --- Comment #11 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] JEY HIND
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||zohaibshehza...@gmail.com --- Comment #13 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] Pakistan Zindabad
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added Summary|JEY HIND|Pakistan Zindabad -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] Pakistan Zindabad
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added CC||usama819ras...@gmail.com --- Comment #14 from Abhinandhan F-16 --- INDIAN ARMY ZINDABAD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109900] Pakistan Zindabad
https://bugs.freedesktop.org/show_bug.cgi?id=109900 Bug ID: 109900 Summary: Pakistan Zindabad Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R100 Assignee: dri-devel@lists.freedesktop.org Reporter: muhammadjawadasghar...@gmail.com QA Contact: dri-devel@lists.freedesktop.org CC: areeshajavai...@hotmail.com, beenish.haneef...@gmail.com, dri-devel@lists.freedesktop.org, hanzila@gmail.com, maazkhan14011...@gmail.com, mijlal...@gmail.com, mir.izz...@gmail.com, mubashir...@gmail.com, musharib.saji...@gmail.com, osamamumta...@gmail.com, shifachisht...@gmail.com, subahnoo...@gmail.com, usama819ras...@gmail.com, wahajakm1...@gmail.com, xee...@gmail.com, zeeade...@gmail.com, zohaibshehza...@gmail.com Depends on: 109889 +++ This bug was initially created as a clone of Bug #109889 +++ INDIAN ARMY ZINDABADj Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=109889 [Bug 109889] Pakistan Zindabad -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] Pakistan Zindabad
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Abhinandhan F-16 changed: What|Removed |Added Blocks||109900 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=109900 [Bug 109900] Pakistan Zindabad -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109863] Testing purpose
https://bugs.freedesktop.org/show_bug.cgi?id=109863 Hanzila changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109900] Pakistan Zindabad
https://bugs.freedesktop.org/show_bug.cgi?id=109900 Michel Dänzer changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |devn...@freedesktop.org |.org| Product|Mesa|a big freedesktop.org fly ||ribbon Group||spam QA Contact|dri-devel@lists.freedesktop | |.org| Component|Drivers/DRI/R100|/dev/null -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109900] Pakistan Zindabad
https://bugs.freedesktop.org/show_bug.cgi?id=109900 Daniel Stone changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED Component|/dev/null |Two Assignee|devn...@freedesktop.org |dan...@fooishbar.org Product|a big freedesktop.org fly |Spam |ribbon | -- You are receiving this mail because: You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109850] there is a problem in frame buffer console.
https://bugs.freedesktop.org/show_bug.cgi?id=109850 Daniel Stone changed: What|Removed |Added Product|a big freedesktop.org fly |Spam |ribbon | Component|/dev/null |Two -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109889] Pakistan Zindabad
https://bugs.freedesktop.org/show_bug.cgi?id=109889 Musharib Iqbal changed: What|Removed |Added Status|RESOLVED|VERIFIED Resolution|INVALID |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101552] Make GALLIUM_HUD lower the grid max value if metric stays much lower all the time
https://bugs.freedesktop.org/show_bug.cgi?id=101552 Michel Dänzer changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Product|DRI |Mesa Version|DRI git |git QA Contact||mesa-dev@lists.freedesktop. ||org Component|General |Mesa core -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator
https://bugs.freedesktop.org/show_bug.cgi?id=109022 Salik changed: What|Removed |Added CC||saliksa...@ymail.com --- Comment #10 from Salik --- *** Bug 109870 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109863] Testing purpose
https://bugs.freedesktop.org/show_bug.cgi?id=109863 Alan Coopersmith changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID CC list accessible|1 |0 Reporter|1 |0 accessible|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data
On Tue, Mar 05, 2019 at 01:47:38PM -0800, Eric Anholt wrote: > Maxime Ripard writes: > > > [ Unknown signature status ] > > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote: > >> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote: > >> > > >> > Maxime Ripard writes: > >> > > >> > > In some cases, in order to accomodate with displays with poor EDIDs, we > >> > > need to ignore that the monitor alledgedly supports audio output and > >> > > disable the audio output. > >> > > > >> > > Signed-off-by: Maxime Ripard > >> > > --- > >> > > drivers/gpu/drm/drm_edid.c | 8 > >> > > 1 file changed, 8 insertions(+) > >> > > > >> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> > > index 990b1909f9d7..c0258b011bb2 100644 > >> > > --- a/drivers/gpu/drm/drm_edid.c > >> > > +++ b/drivers/gpu/drm/drm_edid.c > >> > > @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid) > >> > > } > >> > > EXPORT_SYMBOL(drm_detect_hdmi_monitor); > >> > > > >> > > +static bool ignore_edid_audio = false; > >> > > +module_param(ignore_edid_audio, bool, 0644); > >> > > +MODULE_PARM_DESC(ignore_edid_audio, > >> > > + "Ignore the EDID and always consider that a monitor > >> > > doesn't have audio capabilities"); > >> > > + > >> > > /** > >> > > * drm_detect_monitor_audio - check monitor audio capability > >> > > * @edid: EDID block to scan > >> > > @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid) > >> > > bool has_audio = false; > >> > > int start_offset, end_offset; > >> > > > >> > > + if (ignore_edid_audio) > >> > > + goto end; > >> > > + > >> > > edid_ext = drm_find_cea_extension(edid); > >> > > if (!edid_ext) > >> > > goto end; > >> > > >> > It looks like the motivation for the original flag on Raspberry Pi was > >> > "I've got a non-audio monitor, but the system comes up trying to play > >> > audio to HDMI instead of the analog jack". Do we have some way for DRM > >> > to communicate to ALSA that this is not the right place to try to play > >> > audio by default? > >> > >> Apparently not. We have users using debug knobs in our drivers to > >> disable display audio because ALSA defaults to that rather than other > >> audio. > > > > I guess one way to do this would be to register the card only when an > > audio-capable monitor is connected instead of doing this at probe > > time. I'm not sure how convenient it is for userspace though. > > Oh, right, the HDMI encoder passes the ELD to ALSA, and userspace gets > to use that. So, open source is already doing the right thing, and the > problem was that the old driver talking to the firmware wouldn't, thus > the need for a flag. Ok, I'll drop that patch then. Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 Kamil Páral changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #154 from Kamil Páral --- The commit is present in all the branches, but it got reverted two weeks later: https://cgit.freedesktop.org/mesa/mesa/commit/?id=52098fada7e Where "the previous change" probably refers to: https://cgit.freedesktop.org/mesa/mesa/commit/?id=95eb5e4eed So if you can reliably reproduce a crash with vanilla Mesa and it works fine if you re-apply the patch, it means that Michel's fix doesn't work as intended. Your problem can be the same issue as reported here, or a different issue. I'll reopen this issue to make sure that maintainers don't overlook this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 Kamil Páral changed: What|Removed |Added Version|10.1|18.2 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V6 0/8] make mt7623 clock of hdmi stable
Hi, Wangyan:
On Wed, 2019-03-06 at 09:52 +0800, CK Hu wrote:
> On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> > From: Wangyan Wang
> >
> > V6 adopt maintainer's suggestion.
> > Here is the change list between V5 & V6
> > 1. change "unsigned char mux_flags;" to "u8 mux_flags;" to
> > match with the struct in " clk: mediatek: add MUX_GATE_FLAGS_2".
> >
>
> Hi, Wangyan:
>
> I'm not familiar with this clock system, so I still have some question
> about it, if you could describe more clear, it would help us to speed up
> this review process.
>
> In [1], I find the clock that dpi and hdmi_phy controls,
>
> dpi0: dpi@14014000 {
> clocks = <&mmsys CLK_MM_DPI1_DIGL>,
><&mmsys CLK_MM_DPI1_ENGINE>,
><&topckgen CLK_TOP_TVDPLL>;
> clock-names = "pixel", "engine", "pll";
> };
>
>
> hdmi_phy: phy@10209100 {
> clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
> clock-names = "pll_ref";
> };
>
> In [2], You say that to prevent changing tvdpll would let hdmi stable,
> and this clock is controlled by dpi, why do you modify the control flow
> in hdmi_phy? If these two have relationship, please describe more clear
> because I'm not familiar with this clock system.
>
As discuss offline, in [3] we can find out that CLK_APMIXED_HDMI_REF is
derived from tvdpll, so tvdpll is the parent clock of hdmi_phy_pll.
Therefore, this series should modify hdmi_phy flow as well.
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/mediatek/clk-mt2701.c?h=v5.0#n973
Regards,
CK
> And I think that patch 'drm/mediatek: using new factor for tvdpll in
> MT2701' is the major patch to prevent modifying tvdpll because it reduce
> the factor case. Does MT8173 has the same problem? Just ask, I does not
> require you to modify MT8173 part.
> [1]
> https://github.com/frank-w/BPI-R2-4.14/blob/663f7def421952eb49b2d698eadaff12d02622d2/arch/arm/boot/dts/mt7623.dtsi
> [2]
> http://lists.infradead.org/pipermail/linux-mediatek/2019-February/017693.html
>
>
> Regards,
> CK
>
>
> >
> > chunhui dai (8):
> > drm/mediatek: recalculate hdmi phy clock of MT2701 by querying
> > hardware
> > drm/mediatek: move the setting of fixed divider
> > drm/mediatek: using different flags of clk for HDMI phy
> > drm/mediatek: fix the rate and divder of hdmi phy for MT2701
> > clk: mediatek: add MUX_GATE_FLAGS_2
> > clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel
> > drm/mediatek: using new factor for tvdpll in MT2701
> > drm/mediatek: fix the rate of parent for hdmi phy in MT2701
> >
> > drivers/clk/mediatek/clk-mt2701.c | 4 +-
> > drivers/clk/mediatek/clk-mtk.c | 2 +-
> > drivers/clk/mediatek/clk-mtk.h | 20 ++---
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++--
> > drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 34
> > drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 7 +---
> > drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 56
> > +++---
> > drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++
> > 8 files changed, 102 insertions(+), 52 deletions(-)
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #155 from Michel Dänzer --- Does the problem occur with Mesa built from https://cgit.freedesktop.org/mesa/mesa/commit/?id=52098fada7e ? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Laurent,
Thank you for the patch,
On 02/03/2019 16:17, Laurent Pinchart wrote:
> The R-Car DU driver assumes that a bridge is always connected to the DU
> output. This is valid for the LVDS and HDMI outputs, but the DPAD
> outputs can be connected directly to a panel, in which case no bridge is
> available.
>
> To support this use case, detect whether the entities connected to the
> DU DPAD outputs are encoders or panels based on the number of ports of
> their DT node, and retrieve the corresponding type of DRM objects. For
> panels, additionally create panel bridge instances.
>
> Signed-off-by: Laurent Pinchart
Except for some minor wording on the comment, which I'll let you handle,
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> 1 file changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 8ee4e762f4e5..595ecfa1ff0e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
> .destroy = drm_encoder_cleanup,
> };
>
> +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> +{
> + struct device_node *ports;
> + struct device_node *port;
> + unsigned int num_ports = 0;
> +
> + ports = of_get_child_by_name(node, "ports");
> + if (!ports)
> + ports = of_node_get(node);
> +
> + for_each_child_of_node(ports, port) {
> + if (of_node_name_eq(port, "port"))
> + num_ports++;
> + }
> +
> + of_node_put(node);
> +
> + return num_ports;
> +}
> +
> int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>enum rcar_du_output output,
>struct device_node *enc_node)
> {
> struct rcar_du_encoder *renc;
> struct drm_encoder *encoder;
> - struct drm_bridge *bridge = NULL;
> + struct drm_bridge *bridge;
> int ret;
>
> renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> enc_node, output);
>
> - /* Locate the DRM bridge from the encoder DT node. */
> - bridge = of_drm_find_bridge(enc_node);
> - if (!bridge) {
> - ret = -EPROBE_DEFER;
> - goto done;
> + /*
> + * Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> + * DT node has a single port, consider it describes a panel and create a
consider it as describing? (if it's an assumption that has been made)
consider if it describes? (if it's conditional)
I'm not sure I fully understand the intent of the sentence to correct it
- but it needs a little tweak. The use of the word 'consider' makes me
assume that it might not need a panel bridge, and some further decision
needs to be made, but the code looks like it assumes one port means
there should be a panel - and a bridge will be added.
> + * panel bridge.
> + */
> + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> + output == RCAR_DU_OUTPUT_DPAD1) &&
> + rcar_du_encoder_count_ports(enc_node) == 1) {
> + struct drm_panel *panel = of_drm_find_panel(enc_node);
> +
> + if (IS_ERR(panel)) {
> + ret = PTR_ERR(panel);
> + goto done;
> + }
> +
> + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> +DRM_MODE_CONNECTOR_DPI);
> + if (IS_ERR(bridge)) {
> + ret = PTR_ERR(bridge);
> + goto done;
> + }
> + } else {
> + bridge = of_drm_find_bridge(enc_node);
> + if (!bridge) {
> + ret = -EPROBE_DEFER;
> + goto done;
> + }
> }
>
> ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
>
--
Regards
--
Kieran
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/8] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware
Hi, Wangyan:
On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> From: chunhui dai
>
> Recalculate the rate of this clock, by querying hardware.
>
> Signed-off-by: chunhui dai
> Signed-off-by: wangyan wang
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 7 ++
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 +--
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 35
> ++
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++
> 4 files changed, 46 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 4ef9c57ffd44..13c5e65b9ead 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -29,12 +29,9 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned
> long rate,
> return rate;
> }
>
> -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> -unsigned long parent_rate)
> +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
> {
> - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> -
> - return hdmi_phy->pll_rate;
> + return readl(hdmi_phy->regs + offset);
> }
>
> void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index f39b1fc66612..fdad8b17a915 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -41,6 +41,7 @@ struct mtk_hdmi_phy {
> unsigned int ibias_up;
> };
>
> +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset);
> void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
>u32 bits);
> void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> @@ -50,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
> offset,
> struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
> long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
>unsigned long *parent_rate);
> -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> -unsigned long parent_rate);
>
> extern struct platform_driver mtk_hdmi_phy_driver;
> extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index fcc42dc6ea7f..b25c9dfc432a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -153,6 +153,41 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> RG_HDMITX_DRV_IBIAS_MASK);
> return 0;
> }
> +static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + unsigned long out_rate, val;
> +
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> + & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
> + switch (val) {
> + case 0x00:
> + out_rate = parent_rate;
> + break;
> + case 0x01:
> + out_rate = parent_rate / 2;
> + break;
> + default:
> + out_rate = parent_rate / 4;
> + break;
> + }
> +
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> + & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
> + out_rate *= (val + 1) * 2;
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2)
> + & RG_HDMITX_TX_POSDIV_MASK);
> +
> + out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
> +
> + if (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
> + out_rate = out_rate / 5;
> +
All the register you read here is set in mtk_hdmi_pll_set_rate(), so I
think you could determine the out_rate in mtk_hdmi_pll_set_rate().
Regards,
CK
> + hdmi_phy->pll_rate = out_rate;
> +
> + return hdmi_phy->pll_rate;
> +}
>
> static const struct clk_ops mtk_hdmi_phy_pll_ops = {
> .prepare = mtk_hdmi_pll_prepare,
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> index ed5916b27658..cb23c1e4692a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> @@ -285,6 +285,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> return 0;
> }
>
> +static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> +
> + return hdmi_phy->pll_rate;
> +}
> +
> static const struct clk_ops mtk_hdmi_phy_pll
Re: [PATCH V6 8/8] drm/mediatek: fix the rate of parent for hdmi phy in MT2701
Hi, Wangyan:
On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> From: chunhui dai
>
> We should not change the rate of parent for hdmi phy when
> doing round_rate for this clock. The parent clock of hdmi
> phy must be the same as it. We change it when doing set_rate
> only.
>
> Signed-off-by: chunhui dai
> Signed-off-by: wangyan wang
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 ---
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 11 +++
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
> 4 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 370309d684ec..ca8bc1489f37 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
> .owner = THIS_MODULE,
> };
>
> -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *parent_rate)
> -{
> - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> -
> - hdmi_phy->pll_rate = rate;
> - if (rate <= 7425)
> - *parent_rate = rate;
> - else
> - *parent_rate = rate / 2;
> -
> - return rate;
> -}
> -
> u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
> {
> return readl(hdmi_phy->regs + offset);
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index 446e2acd1926..c6061ad15ff0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -50,9 +50,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy,
> u32 offset,
> void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> u32 val, u32 mask);
> struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
> -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *parent_rate);
> -
> extern struct platform_driver mtk_hdmi_phy_driver;
> extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index 88dd9e812ca0..33893a180c2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -152,6 +152,17 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> RG_HDMITX_DRV_IBIAS_MASK);
> return 0;
> }
> +
> +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> +
> + hdmi_phy->pll_rate = rate;
I think you don't need to save the rate into pll_rate here, pll_rate
would be set in set_rate() or recalc_rate().
Regards,
CK
> +
> + return rate;
> +}
> +
> static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
> {
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> index 63dde42521b8..3a339f516613 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> @@ -285,6 +285,20 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> return 0;
> }
>
> +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> +
> + hdmi_phy->pll_rate = rate;
> + if (rate <= 7425)
> + *parent_rate = rate;
> + else
> + *parent_rate = rate / 2;
> +
> + return rate;
> +}
> +
> static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
> {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Laurent,
On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> The R-Car DU driver assumes that a bridge is always connected to the DU
> output. This is valid for the LVDS and HDMI outputs, but the DPAD
> outputs can be connected directly to a panel, in which case no bridge is
> available.
>
> To support this use case, detect whether the entities connected to the
> DU DPAD outputs are encoders or panels based on the number of ports of
> their DT node, and retrieve the corresponding type of DRM objects. For
> panels, additionally create panel bridge instances.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> 1 file changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 8ee4e762f4e5..595ecfa1ff0e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
> .destroy = drm_encoder_cleanup,
> };
>
> +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> +{
> + struct device_node *ports;
> + struct device_node *port;
> + unsigned int num_ports = 0;
> +
> + ports = of_get_child_by_name(node, "ports");
> + if (!ports)
> + ports = of_node_get(node);
> +
> + for_each_child_of_node(ports, port) {
> + if (of_node_name_eq(port, "port"))
> + num_ports++;
> + }
> +
> + of_node_put(node);
> +
> + return num_ports;
> +}
> +
> int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>enum rcar_du_output output,
>struct device_node *enc_node)
> {
You received a Tested-by, so I might surely be mistaken, but the
caller of this function skips all remote nodes with a single port,
doesn't it?
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rcar-du/rcar_du_kms.c#L308
I don't have any DTS with a panel connected to the DPAD output so, as
a test, I removed all endpoints except endpoint@0 from the 'hdmi0' device
node, and the 'rcar_du_encoder_init()' function never gets called and DU
probing fails with:
rcar-du feb0.display: no encoder found for endpoint
/soc/display@feb0/ports/port@1/endpoint, skipping
What am I missing?
Thanks
j
> struct rcar_du_encoder *renc;
> struct drm_encoder *encoder;
> - struct drm_bridge *bridge = NULL;
> + struct drm_bridge *bridge;
> int ret;
>
> renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> enc_node, output);
>
> - /* Locate the DRM bridge from the encoder DT node. */
> - bridge = of_drm_find_bridge(enc_node);
> - if (!bridge) {
> - ret = -EPROBE_DEFER;
> - goto done;
> + /*
> + * Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> + * DT node has a single port, consider it describes a panel and create a
> + * panel bridge.
> + */
> + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> + output == RCAR_DU_OUTPUT_DPAD1) &&
> + rcar_du_encoder_count_ports(enc_node) == 1) {
Could this be cached?
> + struct drm_panel *panel = of_drm_find_panel(enc_node);
> +
> + if (IS_ERR(panel)) {
> + ret = PTR_ERR(panel);
> + goto done;
> + }
> +
> + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> +DRM_MODE_CONNECTOR_DPI);
> + if (IS_ERR(bridge)) {
> + ret = PTR_ERR(bridge);
> + goto done;
> + }
> + } else {
> + bridge = of_drm_find_bridge(enc_node);
> + if (!bridge) {
> + ret = -EPROBE_DEFER;
> + goto done;
> + }
> }
>
> ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
> --
> Regards,
>
> Laurent Pinchart
>
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109863] Testing purpose
https://bugs.freedesktop.org/show_bug.cgi?id=109863 Andre Klapper changed: What|Removed |Added Component|/dev/null |Two Alias|osamamumta...@gmal.com | Product|a big freedesktop.org fly |Spam |ribbon | -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next-fixes
Hi Dave, Daniel, A few extra patches for the 5.1 merge window. Thanks! Maxime drm-misc-next-fixes-2019-03-06: - Properly mark the ptr_to_compat argument with the __user tag - Merge __drm_atomic_helper_disable_all into drm_atomic_helper_disable_all The following changes since commit 6649a95d35d850e417f125821a803ca7889c713c: drm/komeda: fix build with drm_modeset_helper.h update (2019-02-11 10:36:00 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2019-03-06 for you to fetch changes up to e552f0851070fe4975d610a99910be4e9bf5d7bd: drm: add __user attribute to ptr_to_compat() (2019-03-04 09:55:31 -0500) - Properly mark the ptr_to_compat argument with the __user tag - Merge __drm_atomic_helper_disable_all into drm_atomic_helper_disable_all Ben Dooks (1): drm: add __user attribute to ptr_to_compat() Sean Paul (1): drm: Merge __drm_atomic_helper_disable_all() into drm_atomic_helper_disable_all() drivers/gpu/drm/drm_atomic_helper.c | 119 +--- drivers/gpu/drm/drm_ioc32.c | 6 +- 2 files changed, 59 insertions(+), 66 deletions(-) -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109850] there is a problem in frame buffer console.
https://bugs.freedesktop.org/show_bug.cgi?id=109850 Andre Klapper changed: What|Removed |Added Blocks|| Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id= [Bug ] X server crash whenever 2 xvideo windows are being used simultaneously -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
Hi,
On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> > On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> > >> On Thu, Feb 21, 2019 at 12:32:00PM +0200, Laurent Pinchart wrote:
> > >>> One-shot entries are used as an alternative to committing a complete new
> > >>> display list when a couple of registers need to be written for one frame
> > >>> and then reset to another value for all subsequent frames. This will be
> > >>> used to implement writeback support that will need to enable writeback
> > >>> for the duration of a single frame.
> > >>>
> > >>> Signed-off-by: Laurent Pinchart
> > >>>
> > >>> ---
> > >>> drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
> > >>> drivers/media/platform/vsp1/vsp1_dl.h | 3 ++
> > >>> 2 files changed, 81 insertions(+)
> > >>>
> > >>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> index 886b3a69d329..7b4d252bfde7 100644
> > >>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> @@ -115,6 +115,12 @@ struct vsp1_dl_body {
> > >>>
> > >>> unsigned int num_entries;
> > >>> unsigned int max_entries;
> > >>> +
> > >>> + unsigned int num_patches;
> > >>> + struct {
> > >>> + struct vsp1_dl_entry *entry;
> > >>> + u32 data;
> > >>> + } patches[2];
> > >>> };
> > >>>
> > >>> /**
> > >>> @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
> > >>> return;
> > >>>
> > >>> dlb->num_entries = 0;
> > >>> + dlb->num_patches = 0;
> > >>>
> > >>> spin_lock_irqsave(&dlb->pool->lock, flags);
> > >>> list_add_tail(&dlb->free, &dlb->pool->free);
> > >>> @@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb,
> > >>> u32 reg, u32 data)
> > >>> dlb->num_entries++;
> > >>> }
> > >>>
> > >>> +/**
> > >>> + * vsp1_dl_body_write_oneshot - Write a register to a display list
> > >>> body for a
> > >>> + * single frame
> > >>> + * @dlb: The body
> > >>> + * @reg: The register address
> > >>> + * @value: The register value
> > >>> + * @reset_value: The value to reset the register to at the next vblank
> > >>> + *
> > >>> + * Display lists in continuous mode are re-used by the hardware for
> > >>> successive
> > >>> + * frames until a new display list is committed. Changing the VSP
> > >>> configuration
> > >>> + * normally requires creating and committing a new display list. This
> > >>> function
> > >>> + * offers an alternative race-free way by writing a @value to the
> > >>> @register in
> > >>> + * the display list body for a single frame, specifying in
> > >>> @reset_value the
> > >>> + * value to reset the register to one vblank after the display list is
> > >>> + * committed.
> > >>> + *
> > >>> + * The maximum number of one-shot entries is limited to 2 per display
> > >>> list body,
> > >>> + * and one-shot entries are counted in the total number of entries
> > >>> specified
> > >>> + * when the body is allocated by vsp1_dl_body_alloc().
> > >>> + */
> > >>> +void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32
> > >>> value,
> > >>> + u32 reset_value)
> > >>> +{
> > >>> + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> > >>> + "DLB size exceeded (max %u)", dlb->max_entries))
> > >>> + return;
> > >>> +
> > >>> + if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
> > >>> + "DLB patches size exceeded (max %zu)",
> > >>> + ARRAY_SIZE(dlb->patches)))
> > >>> + return;
> > >>> +
> > >>> + dlb->patches[dlb->num_patches].entry =
> > >>> &dlb->entries[dlb->num_entries];
> > >>> + dlb->patches[dlb->num_patches].data = reset_value;
> > >>> + dlb->num_patches++;
> > >>> +
> > >>> + dlb->entries[dlb->num_entries].addr = reg;
> > >>> + dlb->entries[dlb->num_entries].data = value;
> > >>> + dlb->num_entries++;
> > >>> +}
> > >>> +
> > >>> /*
> > >>> -
> > >>> * Display List Extended Command Management
> > >>> */
> > >>> @@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list
> > >>> *dl)
> > >>> * has at least one body, thus we reinitialise the entries list.
> > >>> */
> > >>> dl->body0->num_entries = 0;
> > >>> + dl->body0->num_patches = 0;
> > >>>
> > >>> list_add_tail(&dl->list, &dl->dlm->free);
> > >>> }
> > >>> @@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl,
> > >>> unsigned int dl_flags)
> > >>> * Display List Manager
> > >>> */
> > >>>
> > >>> +
[Bug 108898] (Recoverable) GPU hangs with GfxBench Manhattan GL tests
https://bugs.freedesktop.org/show_bug.cgi?id=108898 --- Comment #2 from Eero Tamminen --- Hangs are still happening with the latest Mesa (43f40dc7cb234e) and drm-tip kernel (v5.0) git versions in Manhattan test offscreen versions. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: randr: Virtual monitor not present with MST display
Dear Alex, On 03/05/19 20:07, Alex Deucher wrote: > On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: >> Using the MST display Dell UP3214Q (two panels) with an AMD system, >> the virtual monitor object is not created. GDM and Xfce consider both >> panels as separate screens (`xrandr --listmonitors`). >> >> [0.00] Linux version 4.20.13.mx64.248 >> (r...@holidayincambodia.molgen.mpg.de) (gcc version 7.3.0 (GCC)) #1 SMP Wed >> Feb 27 14:10:55 CET 2019 >> >> [ 79.494297] [drm] DM_MST: stopping TM on aconnector: a8109331 >> [id: 56] >> [ 79.494362] [drm] DM_MST: Disabling connector: 776ea22b [id: 63] >> [master: a8109331] >> [ 79.494406] [drm] DM_MST: Disabling connector: 057ebdbb [id: 67] >> [master: a8109331] >> [ 79.781882] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last >> cmd=0x201f0500 >> [ 86.028806] [drm] DM_MST: starting TM on aconnector: a8109331 >> [id: 56] >> [ 86.053072] [drm] DM_MST: added connector: 1c9b49ed [id: 71] >> [master: a8109331] >> [ 86.108540] [drm] SADs count is: -2, don't need to read it >> [ 86.386661] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >> create stream for sink! >> [ 87.237878] [drm] DM_MST: added connector: c3ffcbbb [id: 80] >> [master: a8109331] >> [ 87.293028] [drm] SADs count is: -2, don't need to read it >> [ 206.993344] [drm] DM_MST: stopping TM on aconnector: a8109331 >> [id: 56] >> [ 206.993423] [drm] DM_MST: Disabling connector: 1c9b49ed [id: 71] >> [master: a8109331] >> [ 206.993456] [drm] DM_MST: Disabling connector: c3ffcbbb [id: 80] >> [master: a8109331] >> [ 207.548051] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >> create stream for sink! >> [ 207.603193] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >> create stream for sink! >> [ 207.762388] traps: xfdesktop[2225] general protection fault >> ip:7f588981226c sp:7ffee65af370 error:0 in >> libgobject-2.0.so.0.5800.1[7f58897da000+56000] >> [ 210.320612] [drm] DM_MST: starting TM on aconnector: b456cd59 >> [id: 62] >> [ 210.343497] [drm] DM_MST: added connector: 735839d5 [id: 73] >> [master: b456cd59] >> [ 210.399168] [drm] SADs count is: -2, don't need to read it >> [ 210.404454] [drm] DM_MST: added connector: cccb0c2d [id: 88] >> [master: b456cd59] >> [ 210.675589] [drm] SADs count is: -2, don't need to read it I didn’t provide the output of xrandr in my previous message. $ xrandr --listmonitors Monitors: 2 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 1: +DisplayPort-10 1920/698x2160/392+1920+0 DisplayPort-10 Please find the X.Org X Server log attached. >> With an Intel system, the monitor object is shown. To clarify, the modesetting driver is used with the Intel hardware. >> $ xrandr --listmonitors >> Monitors: 1 >> 0: +Auto-Monitor-1 3840/698x2160/392+0+0 DP-1-9 DP-1-8 >> >> Do you have an idea, what the AMD drivers does differently, and how >> to fix this? > > + dri-devel > > My understanding is that this is handled at the Desktop level rather > than the driver. X exposes the tile info via randr 1.5 and the > desktop environment should handle it as a single monitor. Mutter > handles this in GNOME for example. > > https://cgit.freedesktop.org/xorg/xserver/commit/?id=7e1f86d42b54fb7f6492875e47a718eaeca3069b > https://lists.x.org/archives/xorg-announce/2015-May/002605.html > https://mail.gnome.org/archives/desktop-devel-list/2015-November/msg00018.html As it works with the modesetting driver, it looks to me like Xfce supports it, and it’s a driver issue. The Linux error messages also do not look promising. Any idea, if they are related? Lastly, shouldn’t at least the output of `xrandr` be correct, if everything is set up correctly? Kind regards, Paul [57.665] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [57.665] Build Operating System: Linux 4.19.19.mx64.244 x86_64 [57.665] Current Operating System: Linux inbetweenmove.molgen.mpg.de 4.19.19.mx64.244 #1 SMP Tue Feb 5 13:01:13 CET 2019 x86_64 [57.665] Kernel command line: BOOT_IMAGE=/boot/bzImage-4.19.19.mx64.244 crashkernel=256M root=LABEL=root ro console=ttyS1,115200n8 console=tty0 init=/bin/systemd audit=0 [57.665] Build Date: 27 February 2019 12:32:24PM [57.665] [57.665] Current version of pixman: 0.38.0 [57.665] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [57.665] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [57.665] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 6 13:24:58 2019 [57.665] (==) Using config directory: "/etc/X11/xorg.conf.d" [57.665] (==) Using system confi
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Kieran,
On Wed, Mar 06, 2019 at 10:07:12AM +, Kieran Bingham wrote:
> On 02/03/2019 16:17, Laurent Pinchart wrote:
> > The R-Car DU driver assumes that a bridge is always connected to the DU
> > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > outputs can be connected directly to a panel, in which case no bridge is
> > available.
> >
> > To support this use case, detect whether the entities connected to the
> > DU DPAD outputs are encoders or panels based on the number of ports of
> > their DT node, and retrieve the corresponding type of DRM objects. For
> > panels, additionally create panel bridge instances.
> >
> > Signed-off-by: Laurent Pinchart
>
> Except for some minor wording on the comment, which I'll let you handle,
>
> Reviewed-by: Kieran Bingham
>
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> > 1 file changed, 48 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > index 8ee4e762f4e5..595ecfa1ff0e 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
> > .destroy = drm_encoder_cleanup,
> > };
> >
> > +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> > +{
> > + struct device_node *ports;
> > + struct device_node *port;
> > + unsigned int num_ports = 0;
> > +
> > + ports = of_get_child_by_name(node, "ports");
> > + if (!ports)
> > + ports = of_node_get(node);
> > +
> > + for_each_child_of_node(ports, port) {
> > + if (of_node_name_eq(port, "port"))
> > + num_ports++;
> > + }
> > +
> > + of_node_put(node);
> > +
> > + return num_ports;
> > +}
> > +
> > int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > enum rcar_du_output output,
> > struct device_node *enc_node)
> > {
> > struct rcar_du_encoder *renc;
> > struct drm_encoder *encoder;
> > - struct drm_bridge *bridge = NULL;
> > + struct drm_bridge *bridge;
> > int ret;
> >
> > renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> > @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> > enc_node, output);
> >
> > - /* Locate the DRM bridge from the encoder DT node. */
> > - bridge = of_drm_find_bridge(enc_node);
> > - if (!bridge) {
> > - ret = -EPROBE_DEFER;
> > - goto done;
> > + /*
> > +* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> > +* DT node has a single port, consider it describes a panel and create a
>
>
> consider it as describing? (if it's an assumption that has been made)
>
> consider if it describes? (if it's conditional)
>
> I'm not sure I fully understand the intent of the sentence to correct it
> - but it needs a little tweak. The use of the word 'consider' makes me
> assume that it might not need a panel bridge, and some further decision
> needs to be made, but the code looks like it assumes one port means
> there should be a panel - and a bridge will be added.
Should I write it as "assume that it ..." ? I considered "consider" as
being less conditional than "assume", but I'll trust your judgement on
that.
> > +* panel bridge.
> > +*/
> > + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> > +output == RCAR_DU_OUTPUT_DPAD1) &&
> > + rcar_du_encoder_count_ports(enc_node) == 1) {
> > + struct drm_panel *panel = of_drm_find_panel(enc_node);
> > +
> > + if (IS_ERR(panel)) {
> > + ret = PTR_ERR(panel);
> > + goto done;
> > + }
> > +
> > + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> > + DRM_MODE_CONNECTOR_DPI);
> > + if (IS_ERR(bridge)) {
> > + ret = PTR_ERR(bridge);
> > + goto done;
> > + }
> > + } else {
> > + bridge = of_drm_find_bridge(enc_node);
> > + if (!bridge) {
> > + ret = -EPROBE_DEFER;
> > + goto done;
> > + }
> > }
> >
> > ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Jacopo,
On Wed, Mar 06, 2019 at 11:03:32AM +0100, Jacopo Mondi wrote:
> On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> > The R-Car DU driver assumes that a bridge is always connected to the DU
> > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > outputs can be connected directly to a panel, in which case no bridge is
> > available.
> >
> > To support this use case, detect whether the entities connected to the
> > DU DPAD outputs are encoders or panels based on the number of ports of
> > their DT node, and retrieve the corresponding type of DRM objects. For
> > panels, additionally create panel bridge instances.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> > 1 file changed, 48 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > index 8ee4e762f4e5..595ecfa1ff0e 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
> > .destroy = drm_encoder_cleanup,
> > };
> >
> > +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> > +{
> > + struct device_node *ports;
> > + struct device_node *port;
> > + unsigned int num_ports = 0;
> > +
> > + ports = of_get_child_by_name(node, "ports");
> > + if (!ports)
> > + ports = of_node_get(node);
> > +
> > + for_each_child_of_node(ports, port) {
> > + if (of_node_name_eq(port, "port"))
> > + num_ports++;
> > + }
> > +
> > + of_node_put(node);
> > +
> > + return num_ports;
> > +}
> > +
> > int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > enum rcar_du_output output,
> > struct device_node *enc_node)
> > {
>
> You received a Tested-by, so I might surely be mistaken, but the
> caller of this function skips all remote nodes with a single port,
> doesn't it?
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rcar-du/rcar_du_kms.c#L308
>
> I don't have any DTS with a panel connected to the DPAD output so, as
> a test, I removed all endpoints except endpoint@0 from the 'hdmi0' device
> node, and the 'rcar_du_encoder_init()' function never gets called and DU
> probing fails with:
> rcar-du feb0.display: no encoder found for endpoint
> /soc/display@feb0/ports/port@1/endpoint, skipping
>
> What am I missing?
You're missing drm-next :-)
https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/rcar-du/rcar_du_kms.c#n331
> > struct rcar_du_encoder *renc;
> > struct drm_encoder *encoder;
> > - struct drm_bridge *bridge = NULL;
> > + struct drm_bridge *bridge;
> > int ret;
> >
> > renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> > @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> > enc_node, output);
> >
> > - /* Locate the DRM bridge from the encoder DT node. */
> > - bridge = of_drm_find_bridge(enc_node);
> > - if (!bridge) {
> > - ret = -EPROBE_DEFER;
> > - goto done;
> > + /*
> > +* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> > +* DT node has a single port, consider it describes a panel and create a
> > +* panel bridge.
> > +*/
> > + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> > +output == RCAR_DU_OUTPUT_DPAD1) &&
> > + rcar_du_encoder_count_ports(enc_node) == 1) {
>
> Could this be cached?
How so ? This function is run once per enc_node, so the cache wouldn't
be used again, would it ?
> > + struct drm_panel *panel = of_drm_find_panel(enc_node);
> > +
> > + if (IS_ERR(panel)) {
> > + ret = PTR_ERR(panel);
> > + goto done;
> > + }
> > +
> > + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> > + DRM_MODE_CONNECTOR_DPI);
> > + if (IS_ERR(bridge)) {
> > + ret = PTR_ERR(bridge);
> > + goto done;
> > + }
> > + } else {
> > + bridge = of_drm_find_bridge(enc_node);
> > + if (!bridge) {
> > + ret = -EPROBE_DEFER;
> > + goto done;
> > + }
> > }
> >
> > ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [TWO BUGs] etnaviv crashes overnight
On Tue, Feb 26, 2019 at 11:02:48AM +0100, Lucas Stach wrote:
> Hi Russell,
>
> Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux
> admin:
> > I'm not sure when this happened, only that it happened sometime
> > overnight. It was left running an Xfce desktop having only logged in,
> > but with the monitor disconnected. Fedora 23 plus xf86-video-armada.
> >
> > I don't have any more information than that and the kernel messages
> > below.
>
> Thanks for the report! Both of those issues are caused by the GPU
> scheduler failing to put the scheduler fence callback execution into a
> work item, like it normally does, in the dying sched_entity cleanup.
> This causes multiple code paths which expect to be called from a clean
> process context to be called from the same IRQ context with a number of
> locks potentially already held.
>
> It will take me some time to work through the corners of this code, but
> I should have a patch fixing this later today.
Hi Lucas,
Did you get a chance to patch this bug?
Thanks.
>
> Regards,
> Lucas
>
> > [51328.909729]
> > [51328.915044] WARNING: possible recursive locking detected
> > [51328.920361] 4.20.0+ #307 Not tainted
> > [51328.923939]
> > [51328.929254] Xorg/5379 is trying to acquire lock:
> > [51328.933874] cd12d5e4 (&(&fence->lock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51328.941638]
> > [51328.941638] but task is already holding lock:
> > [51328.947474] cd12d6a4 (&(&fence->lock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51328.955226]
> > [51328.955226] other info that might help us debug this:
> > [51328.961756] Possible unsafe locking scenario:
> > [51328.961756]
> > [51328.967678]CPU0
> > [51328.970127]
> > [51328.976761] lock(&(&fence->lock)->rlock);
> > [51328.980948]
> > [51328.980948] *** DEADLOCK ***
> > [51328.980948]
> > [51328.986871] May be due to missing lock nesting notation
> > [51328.986871]
> > [51328.993663] 4 locks held by Xorg/5379:
> > [51328.997414] #0: d8c6bdd0 (reservation_ww_class_acquire){+.+.}, at:
> > drm_ioctl_kernel+0x90/0xc8
> > [51329.006040] #1: d879e2ac (&suballoc->lock){+.+.}, at:
> > etnaviv_cmdbuf_init+0x5c/0x16c [etnaviv]
> > [51329.014784] #2: d900dd88 (&(&gpu->fence_spinlock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51329.023668] #3: cd12d6a4 (&(&fence->lock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51329.031854]
> > [51329.031854] stack backtrace:
> > [51329.036218] CPU: 0 PID: 5379 Comm: Xorg Not tainted 4.20.0+ #307
> > [51329.042227] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [51329.048772] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x14)
> > [51329.056527] [] (show_stack) from []
> > (dump_stack+0x9c/0xd4)
> > [51329.063763] [] (dump_stack) from []
> > (__lock_acquire+0x1270/0x19b8)
> > [51329.071689] [] (__lock_acquire) from []
> > (lock_acquire+0xc4/0x1dc)
> > [51329.079529] [] (lock_acquire) from []
> > (_raw_spin_lock_irqsave+0x44/0x58)
> > [51329.087975] [] (_raw_spin_lock_irqsave) from []
> > (dma_fence_signal+0x9c/0x1d4)
> > [51329.096872] [] (dma_fence_signal) from []
> > (drm_sched_entity_kill_jobs_cb+0x14/0x78 [gpu_sched])
> > [51329.107327] [] (drm_sched_entity_kill_jobs_cb [gpu_sched])
> > from [] (dma_fence_signal+0xe0/0x1d4)
> > [51329.117866] [] (dma_fence_signal) from []
> > (drm_sched_process_job+0x60/0x1a4 [gpu_sched])
> > [51329.127710] [] (drm_sched_process_job [gpu_sched]) from
> > [] (dma_fence_signal+0xe0/0x1d4)
> > [51329.137569] [] (dma_fence_signal) from []
> > (irq_handler+0xc8/0x1d8 [etnaviv])
> > [51329.146389] [] (irq_handler [etnaviv]) from []
> > (__handle_irq_event_percpu+0x98/0x378)
> > [51329.155966] [] (__handle_irq_event_percpu) from []
> > (handle_irq_event_percpu+0x1c/0x58)
> > [51329.165629] [] (handle_irq_event_percpu) from []
> > (handle_irq_event+0x38/0x5c)
> > [51329.174511] [] (handle_irq_event) from []
> > (handle_fasteoi_irq+0x94/0x124)
> > [51329.183044] [] (handle_fasteoi_irq) from []
> > (generic_handle_irq+0x18/0x28)
> > [51329.191665] [] (generic_handle_irq) from []
> > (__handle_domain_irq+0x54/0xb0)
> > [51329.200374] [] (__handle_domain_irq) from []
> > (gic_handle_irq+0x48/0x98)
> > [51329.208735] [] (gic_handle_irq) from []
> > (__irq_svc+0x70/0x98)
> > [51329.216221] Exception stack(0xd8c6bc28 to 0xd8c6bc70)
> > [51329.221279] bc20: 0001 0011 d8c6bc78 c2005940
> > d879e2ac
> > [51329.229462] bc40: c0c2c580 600b0013 c0b98568
> > c13bb508 d8c6bc78
> > [51329.237643] bc60: c0085804 c0087860 800b0013
> > [51329.242704] [] (__irq_svc) from []
> > (lock_acquire+0xdc/0x1dc)
> > [51329.250111] [] (lock_acquire) from []
> > (__mutex_lock+0x50/0x8b8)
> > [51329.25] [] (__mutex_lock) from []
> > (mutex_lock_nested+0x1c/0x24)
> > [51329.
Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data
On Tue, Mar 05, 2019 at 01:47:38PM -0800, Eric Anholt wrote: > Maxime Ripard writes: > > > [ Unknown signature status ] > > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote: > >> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote: > >> > > >> > Maxime Ripard writes: > >> > > >> > > In some cases, in order to accomodate with displays with poor EDIDs, we > >> > > need to ignore that the monitor alledgedly supports audio output and > >> > > disable the audio output. > >> > > > >> > > Signed-off-by: Maxime Ripard > >> > > --- > >> > > drivers/gpu/drm/drm_edid.c | 8 > >> > > 1 file changed, 8 insertions(+) > >> > > > >> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> > > index 990b1909f9d7..c0258b011bb2 100644 > >> > > --- a/drivers/gpu/drm/drm_edid.c > >> > > +++ b/drivers/gpu/drm/drm_edid.c > >> > > @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid) > >> > > } > >> > > EXPORT_SYMBOL(drm_detect_hdmi_monitor); > >> > > > >> > > +static bool ignore_edid_audio = false; > >> > > +module_param(ignore_edid_audio, bool, 0644); > >> > > +MODULE_PARM_DESC(ignore_edid_audio, > >> > > + "Ignore the EDID and always consider that a monitor > >> > > doesn't have audio capabilities"); > >> > > + > >> > > /** > >> > > * drm_detect_monitor_audio - check monitor audio capability > >> > > * @edid: EDID block to scan > >> > > @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid) > >> > > bool has_audio = false; > >> > > int start_offset, end_offset; > >> > > > >> > > + if (ignore_edid_audio) > >> > > + goto end; > >> > > + > >> > > edid_ext = drm_find_cea_extension(edid); > >> > > if (!edid_ext) > >> > > goto end; > >> > > >> > It looks like the motivation for the original flag on Raspberry Pi was > >> > "I've got a non-audio monitor, but the system comes up trying to play > >> > audio to HDMI instead of the analog jack". Do we have some way for DRM > >> > to communicate to ALSA that this is not the right place to try to play > >> > audio by default? > >> > >> Apparently not. We have users using debug knobs in our drivers to > >> disable display audio because ALSA defaults to that rather than other > >> audio. > > > > I guess one way to do this would be to register the card only when an > > audio-capable monitor is connected instead of doing this at probe > > time. I'm not sure how convenient it is for userspace though. > > Oh, right, the HDMI encoder passes the ELD to ALSA, and userspace gets > to use that. So, open source is already doing the right thing, and the > problem was that the old driver talking to the firmware wouldn't, thus > the need for a flag. I started to look into this, and while on my laptop, the ELD seems to be exposed as part of /proc/asound/card0/eld*, there's no such file on the RPi with a 5.0 kernel (and an HDMI monitor with audio support, obviously). Is it something that used to work at some point? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Laurent!
On Wed, Mar 06, 2019 at 03:13:55PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Mar 06, 2019 at 11:03:32AM +0100, Jacopo Mondi wrote:
> > On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> > > The R-Car DU driver assumes that a bridge is always connected to the DU
> > > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > > outputs can be connected directly to a panel, in which case no bridge is
> > > available.
> > >
> > > To support this use case, detect whether the entities connected to the
> > > DU DPAD outputs are encoders or panels based on the number of ports of
> > > their DT node, and retrieve the corresponding type of DRM objects. For
> > > panels, additionally create panel bridge instances.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> > > 1 file changed, 48 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > index 8ee4e762f4e5..595ecfa1ff0e 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs =
> > > {
> > > .destroy = drm_encoder_cleanup,
> > > };
> > >
> > > +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> > > +{
> > > + struct device_node *ports;
> > > + struct device_node *port;
> > > + unsigned int num_ports = 0;
> > > +
> > > + ports = of_get_child_by_name(node, "ports");
> > > + if (!ports)
> > > + ports = of_node_get(node);
> > > +
> > > + for_each_child_of_node(ports, port) {
> > > + if (of_node_name_eq(port, "port"))
> > > + num_ports++;
> > > + }
> > > +
> > > + of_node_put(node);
> > > +
> > > + return num_ports;
> > > +}
> > > +
> > > int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > >enum rcar_du_output output,
> > >struct device_node *enc_node)
> > > {
> >
> > You received a Tested-by, so I might surely be mistaken, but the
> > caller of this function skips all remote nodes with a single port,
> > doesn't it?
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rcar-du/rcar_du_kms.c#L308
> >
> > I don't have any DTS with a panel connected to the DPAD output so, as
> > a test, I removed all endpoints except endpoint@0 from the 'hdmi0' device
> > node, and the 'rcar_du_encoder_init()' function never gets called and DU
> > probing fails with:
> > rcar-du feb0.display: no encoder found for endpoint
> > /soc/display@feb0/ports/port@1/endpoint, skipping
> >
> > What am I missing?
>
> You're missing drm-next :-)
>
> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/rcar-du/rcar_du_kms.c#n331
Oh, I see!
Thanks, with this clarified, please add
Reviewed-by: Jacopo Mondi
Thanks
j
>
> > > struct rcar_du_encoder *renc;
> > > struct drm_encoder *encoder;
> > > - struct drm_bridge *bridge = NULL;
> > > + struct drm_bridge *bridge;
> > > int ret;
> > >
> > > renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> > > @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > > dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> > > enc_node, output);
> > >
> > > - /* Locate the DRM bridge from the encoder DT node. */
> > > - bridge = of_drm_find_bridge(enc_node);
> > > - if (!bridge) {
> > > - ret = -EPROBE_DEFER;
> > > - goto done;
> > > + /*
> > > + * Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> > > + * DT node has a single port, consider it describes a panel and create a
> > > + * panel bridge.
> > > + */
> > > + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> > > + output == RCAR_DU_OUTPUT_DPAD1) &&
> > > + rcar_du_encoder_count_ports(enc_node) == 1) {
> >
> > Could this be cached?
>
> How so ? This function is run once per enc_node, so the cache wouldn't
> be used again, would it ?
>
> > > + struct drm_panel *panel = of_drm_find_panel(enc_node);
> > > +
> > > + if (IS_ERR(panel)) {
> > > + ret = PTR_ERR(panel);
> > > + goto done;
> > > + }
> > > +
> > > + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> > > +DRM_MODE_CONNECTOR_DPI);
> > > + if (IS_ERR(bridge)) {
> > > + ret = PTR_ERR(bridge);
> > > + goto done;
> > > + }
> > > + } else {
> > > + bridge = of_drm_find_bridge(enc_node);
> > > + if (!bridge) {
> > > + ret = -EPROBE_DEFER;
> > > + goto done;
> > > + }
> > > }
> > >
> > > ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
>
> --
> Regards,
>
> Laurent Pinchart
signature.asc
Description: PGP signature
_
Re: [TWO BUGs] etnaviv crashes overnight
Hi Russell,
Am Mittwoch, den 06.03.2019, 13:20 + schrieb Russell King - ARM Linux admin:
> On Tue, Feb 26, 2019 at 11:02:48AM +0100, Lucas Stach wrote:
> > Hi Russell,
> >
> > Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux
> > admin:
> > > I'm not sure when this happened, only that it happened sometime
> > > overnight. It was left running an Xfce desktop having only logged in,
> > > but with the monitor disconnected. Fedora 23 plus xf86-video-armada.
> > >
> > > I don't have any more information than that and the kernel messages
> > > below.
> >
> > Thanks for the report! Both of those issues are caused by the GPU
> > scheduler failing to put the scheduler fence callback execution into a
> > work item, like it normally does, in the dying sched_entity cleanup.
> > This causes multiple code paths which expect to be called from a clean
> > process context to be called from the same IRQ context with a number of
> > locks potentially already held.
> >
> > It will take me some time to work through the corners of this code, but
> > I should have a patch fixing this later today.
>
> Hi Lucas,
>
> Did you get a chance to patch this bug?
I have the following patch, but it didn't get close to the amount of
testing required for such a change yet. Maybe you can run it and see if
something falls out?
Regards,
Lucas
>8-
From badd5fa28e2e9369bcd765f110bc6b8756207bcf Mon Sep 17 00:00:00 2001
From: Lucas Stach
Date: Wed, 27 Feb 2019 18:11:48 +0100
Subject: [PATCH] drm/scheduler: put killed job cleanup to worker
drm_sched_entity_kill_jobs_cb() is called right from the last scheduled
job finished fence signaling. As this might happen from IRQ context we
now end up calling the GPU driver free_job callback in IRQ context, while
all other paths call it from normal process context.
Etnaviv in particular calls core kernel functions that are only valid to
be called from process context when freeing the job. Other drivers might
have similar issues, but I did not validate this. Fix this by punting
the cleanup work into a work item, so the driver expectations are met.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/scheduler/sched_entity.c | 30 ++--
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 3e22a54a99c2..dde875c6ca50 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -188,19 +188,10 @@ long drm_sched_entity_flush(struct drm_sched_entity
*entity, long timeout)
}
EXPORT_SYMBOL(drm_sched_entity_flush);
-/**
- * drm_sched_entity_kill_jobs - helper for drm_sched_entity_kill_jobs
- *
- * @f: signaled fence
- * @cb: our callback structure
- *
- * Signal the scheduler finished fence when the entity in question is killed.
- */
-static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
- struct dma_fence_cb *cb)
+static void drm_sched_entity_kill_work(struct work_struct *work)
{
- struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-finish_cb);
+ struct drm_sched_job *job = container_of(work, struct drm_sched_job,
+finish_work);
drm_sched_fence_finished(job->s_fence);
WARN_ON(job->s_fence->parent);
@@ -208,6 +199,15 @@ static void drm_sched_entity_kill_jobs_cb(struct dma_fence
*f,
job->sched->ops->free_job(job);
}
+static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
+ struct dma_fence_cb *cb)
+{
+ struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
+finish_cb);
+
+ schedule_work(&job->finish_work);
+}
+
/**
* drm_sched_entity_kill_jobs - Make sure all remaining jobs are killed
*
@@ -227,6 +227,12 @@ static void drm_sched_entity_kill_jobs(struct
drm_sched_entity *entity)
drm_sched_fence_scheduled(s_fence);
dma_fence_set_error(&s_fence->finished, -ESRCH);
+ /*
+* Replace regular finish work function with one that just
+* kills the job.
+*/
+ job->finish_work.func = drm_sched_entity_kill_work;
+
/*
* When pipe is hanged by older entity, new entity might
* not even have chance to submit it's first job to HW
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109921] [CI][Runner] Do not mistake KERN_NOTICE for a WARNING
https://bugs.freedesktop.org/show_bug.cgi?id=109921 Bug ID: 109921 Summary: [CI][Runner] Do not mistake KERN_NOTICE for a WARNING Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: martin.pe...@free.fr Original bug: https://bugs.freedesktop.org/show_bug.cgi?id=107956 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109921] [CI][Runner] Do not mistake KERN_NOTICE for a WARNING
https://bugs.freedesktop.org/show_bug.cgi?id=109921 Martin Peres changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |arkadiusz.hi...@intel.com |.org| --- Comment #1 from Martin Peres --- Assigning Arek, as he already started working on this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] phy: Add driver for mixel dphy found on imx8
Hi, On Fri, Feb 08, 2019 at 11:55:41AM +, Robert Chiras wrote: > Hi Guido > > On Vi, 2019-02-08 at 12:40 +0100, Guido Günther wrote: > > Hi Robert, > > On Wed, Feb 06, 2019 at 03:28:07PM +, Robert Chiras wrote: > > > > > > Hi Guido, > > > > > > Thanks for picking this up. It's interesting to see that a lot has > > > changed in the PHY API and the phy can be now configured through > > > the > > > API instead of exported function as I did in the NXP tree. > > > > > > I was going through your implementation and I noticed you also > > > added > > > the phy_ref clock to this driver too. This is good, since the DPHY > > > needs this clock, but I have a question related to the other > > > clocks: > > > According to the Northwest Logic reference manual (the DSI host > > > that > > > uses this DPHY), the host relies on the TX clock in order to > > > configure > > > the DPHY. Is this driver relying on it's user to also enable the TX > > > clock? > > Yes, I think that would be best. In fact due to lack of reference > > manuals for nwl and mixel I didn't even know exactly which clocks > > needed > > to be on already so I currently set for enabling this after the nwl > > clocks. Are these manuals available publicly somewhere, I couldn't > > find > > them? > > That's OK, I guess. Regarding the manuals: we have them from the vendor > so I can't share them. Too bad. Any contact I could ping there would also be nice? > > > > > > > > > Also: did you test this driver? Because I have a version of the > > > patches > > > from NXP tree rebased on top of latest linux-next and I have a > > > working > > Hmm...could you (maybe off list) send the boot output with DEBUG 1 > > at the top of the driver and drm.debug=0x2f on the kernel command > > line? > > Maybe I can spot something. > > Eventually I got it working. On i.MX8MQ there is a System Reset > Controller that controls the clocks on each individual block. For some > reason, before asserting the MIPI clock domain in this SRC, a delay is > needed (right now, the hack is a sleep). Probably there is a component > that is not ready yet. Right now I am trying to figure out which one is > it and how can I wait for it. > > > > > > > > > version of eLCDIF with Raydium RM67191 DSI panel on mScale850D > > > (i.MX8MQ). And I tried using this driver but there is no signal on > > > the > > > screen, even through the register values are all identical. Next, > > > I'll > > > try to debug why isn't this working on my setup. > > I'm testing this on the Librem 5 devkit with a rockchip panel atm > > using > > DCSS not eLCDIF though. My plan is to move to the NXP evk in the not > > so > > far future to make this easier to reproduce. > > Good to know. Currently I am working on the eLCDIF pipeline on 850D to > make it ready for upstream. Since you took my DPHY driver and submitted > upstream in a better shape, I will make use of it. Cool. I have an initial version of nwl mostly in shape now too (hope to send it out in a couple of days). eLCDIF will be handy to test the whole stack on 5.x. Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [v2] gpu: host1x: avoid IOMMU_API build error
When the iommu API is disabled, the host1x driver fails to build:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
[-Werror=implicit-function-declaration]
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
^~~~
iommu_fwspec_free
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: initialization of 'struct
iommu_fwspec *' from 'int' makes pointer from integer without a cast
[-Werror=int-conversion]
drivers/gpu/host1x/hw/channel_hw.c:119:23: error: 'struct iommu_fwspec' has no
member named 'ids'
u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
^~
cc1: all warnings being treated as errors
As Mikko explains, we should program SMMU bypass (0x7f) if that
happens.
Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
Suggested-by: Mikko Perttunen
Signed-off-by: Arnd Bergmann
v2: fall back to 0x7f sid
---
drivers/gpu/host1x/hw/channel_hw.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index 27101c04a827..0c0eb43abf65 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -115,8 +115,12 @@ static inline void synchronize_syncpt_base(struct
host1x_job *job)
static void host1x_channel_set_streamid(struct host1x_channel *channel)
{
#if HOST1X_HW >= 6
+ u32 sid = 0x7f;
+#ifdef CONFIG_IOMMU_API
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
- u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
+ if (spec)
+ sid = spec->ids[0] & 0x;
+#endif
host1x_ch_writel(channel, sid, HOST1X_CHANNEL_SMMU_STREAMID);
#endif
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Use 16bpp by default for the fbdev buffer
The preferred bpp for the fbdev emulation buffer has been 32 so far, which means that by default we will allocate an 8MB buffer with a 1920x1080 resolution. Worse this memory will be allocated from the CMA pool, and will never be freed even if we don't use the fbdev emulation. Therefore, reducing it is a big deal, and switching to 16bpp by default will gain us around 4MB at 1920x1080, while keeping decent color depth. And users still have the option to switch to 32bpp using the kernel command line. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 52576dee809e..c38cf64837e1 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -286,7 +286,7 @@ static int vc4_drm_bind(struct device *dev) vc4_kms_load(drm); - drm_fbdev_generic_setup(drm, 32); + drm_fbdev_generic_setup(drm, 16); return 0; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v2] gpu: host1x: avoid IOMMU_API build error
On 6.3.2019 15.57, Arnd Bergmann wrote:
When the iommu API is disabled, the host1x driver fails to build:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
[-Werror=implicit-function-declaration]
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
^~~~
iommu_fwspec_free
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: initialization of 'struct
iommu_fwspec *' from 'int' makes pointer from integer without a cast
[-Werror=int-conversion]
drivers/gpu/host1x/hw/channel_hw.c:119:23: error: 'struct iommu_fwspec' has no
member named 'ids'
u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
^~
cc1: all warnings being treated as errors
As Mikko explains, we should program SMMU bypass (0x7f) if that
happens.
Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
Suggested-by: Mikko Perttunen
Signed-off-by: Arnd Bergmann
v2: fall back to 0x7f sid
---
drivers/gpu/host1x/hw/channel_hw.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index 27101c04a827..0c0eb43abf65 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -115,8 +115,12 @@ static inline void synchronize_syncpt_base(struct
host1x_job *job)
static void host1x_channel_set_streamid(struct host1x_channel *channel)
{
#if HOST1X_HW >= 6
+ u32 sid = 0x7f;
+#ifdef CONFIG_IOMMU_API
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
- u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
+ if (spec)
+ sid = spec->ids[0] & 0x;
+#endif
host1x_ch_writel(channel, sid, HOST1X_CHANNEL_SMMU_STREAMID);
#endif
Reviewed-by: Mikko Perttunen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/3] drm/vc4: Add a load tracker
On Wed, Feb 20, 2019 at 09:56:39AM -0800, Eric Anholt wrote: > Paul Kocialkowski writes: > > > Hi, > > > > Here is a fourth iteration of the VC4 load tracking series, which was > > initially developed by Boris Brezillon and that I have now taken over. > > > > This new iteration takes in account comments from v3 and comes with a > > new approach for avoiding underrun reports when reconfiguring the > > pipeline. It is now based on detection instead of delaying the underrun > > interrupt unmasking. > > > > It can be tested with a dedicated IGT GPU Tools series: > > VC4 load tracker testing > > Series is: > > Reviewed-by: Eric Anholt > > Thanks for persisting on this! Applied all three patches to drm-misc-next. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> > On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> > >> On Thu, Feb 21, 2019 at 12:32:00PM +0200, Laurent Pinchart wrote:
> > >>> One-shot entries are used as an alternative to committing a complete new
> > >>> display list when a couple of registers need to be written for one frame
> > >>> and then reset to another value for all subsequent frames. This will be
> > >>> used to implement writeback support that will need to enable writeback
> > >>> for the duration of a single frame.
> > >>>
> > >>> Signed-off-by: Laurent Pinchart
> > >>>
> > >>> ---
> > >>> drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
> > >>> drivers/media/platform/vsp1/vsp1_dl.h | 3 ++
> > >>> 2 files changed, 81 insertions(+)
> > >>>
> > >>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> index 886b3a69d329..7b4d252bfde7 100644
> > >>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> @@ -115,6 +115,12 @@ struct vsp1_dl_body {
> > >>>
> > >>> unsigned int num_entries;
> > >>> unsigned int max_entries;
> > >>> +
> > >>> + unsigned int num_patches;
> > >>> + struct {
> > >>> + struct vsp1_dl_entry *entry;
> > >>> + u32 data;
> > >>> + } patches[2];
> > >>> };
> > >>>
> > >>> /**
> > >>> @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
> > >>> return;
> > >>>
> > >>> dlb->num_entries = 0;
> > >>> + dlb->num_patches = 0;
> > >>>
> > >>> spin_lock_irqsave(&dlb->pool->lock, flags);
> > >>> list_add_tail(&dlb->free, &dlb->pool->free);
> > >>> @@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb,
> > >>> u32 reg, u32 data)
> > >>> dlb->num_entries++;
> > >>> }
> > >>>
> > >>> +/**
> > >>> + * vsp1_dl_body_write_oneshot - Write a register to a display list
> > >>> body for a
> > >>> + * single frame
> > >>> + * @dlb: The body
> > >>> + * @reg: The register address
> > >>> + * @value: The register value
> > >>> + * @reset_value: The value to reset the register to at the next vblank
> > >>> + *
> > >>> + * Display lists in continuous mode are re-used by the hardware for
> > >>> successive
> > >>> + * frames until a new display list is committed. Changing the VSP
> > >>> configuration
> > >>> + * normally requires creating and committing a new display list. This
> > >>> function
> > >>> + * offers an alternative race-free way by writing a @value to the
> > >>> @register in
> > >>> + * the display list body for a single frame, specifying in
> > >>> @reset_value the
> > >>> + * value to reset the register to one vblank after the display list is
> > >>> + * committed.
> > >>> + *
> > >>> + * The maximum number of one-shot entries is limited to 2 per display
> > >>> list body,
> > >>> + * and one-shot entries are counted in the total number of entries
> > >>> specified
> > >>> + * when the body is allocated by vsp1_dl_body_alloc().
> > >>> + */
> > >>> +void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32
> > >>> value,
> > >>> + u32 reset_value)
> > >>> +{
> > >>> + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> > >>> + "DLB size exceeded (max %u)", dlb->max_entries))
> > >>> + return;
> > >>> +
> > >>> + if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
> > >>> + "DLB patches size exceeded (max %zu)",
> > >>> + ARRAY_SIZE(dlb->patches)))
> > >>> + return;
> > >>> +
> > >>> + dlb->patches[dlb->num_patches].entry =
> > >>> &dlb->entries[dlb->num_entries];
> > >>> + dlb->patches[dlb->num_patches].data = reset_value;
> > >>> + dlb->num_patches++;
> > >>> +
> > >>> + dlb->entries[dlb->num_entries].addr = reg;
> > >>> + dlb->entries[dlb->num_entries].data = value;
> > >>> + dlb->num_entries++;
> > >>> +}
> > >>> +
> > >>> /*
> > >>> -
> > >>> * Display List Extended Command Management
> > >>> */
> > >>> @@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list
> > >>> *dl)
> > >>> * has at least one body, thus we reinitialise the entries list.
> > >>> */
> > >>> dl->body0->num_entries = 0;
> > >>> + dl->body0->num_patches = 0;
> > >>>
> > >>> list_add_tail(&dl->list, &dl->dlm->free);
> > >>> }
> > >>> @@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl,
> > >>> unsigned int dl_flags)
> > >>> * Display List Manager
> > >>> */
> > >>>
> > >>> +/**
>
Re: [PATCH v2] drm/vkms: Add overlay plane support
On Tuesday, 2019-03-05 21:54:47 +0530, Mamta Shukla wrote:
> Add overlay plane support in vkms aligned with cursor and primary
> plane with module option 'enable_overlay' to enable/disable overlay
> plane while testing.
>
> This currently passes plane-position-covered-pipe-A-plane subtest
> from IGT kms_plane test.
>
> Signed-off-by: Mamta Shukla
> ---
> change in v2:
> -Fix warning: return makes pointer from integer without a cast using
> ERR_PTR
>
> drivers/gpu/drm/vkms/vkms_crc.c | 36 +++
> drivers/gpu/drm/vkms/vkms_drv.c | 4
> drivers/gpu/drm/vkms/vkms_drv.h | 8 +++
> drivers/gpu/drm/vkms/vkms_plane.c | 36 ++-
> 4 files changed, 79 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 4dd6c155363d..ac3ed863cf34 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -109,6 +109,25 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> }
> }
>
> +static void compose_overlay(struct vkms_crc_data *overlay_crc,
> + struct vkms_crc_data *primary_crc, void *vaddr_out)
> {
> + struct drm_gem_object *overlay_obj;
> + struct vkms_gem_object *overlay_vkms_obj;
> +
> + overlay_obj = drm_gem_fb_get_obj(&overlay_crc->fb, 0);
> + overlay_vkms_obj = drm_gem_to_vkms_gem(overlay_obj);
> + mutex_lock(&overlay_vkms_obj->pages_lock);
> + if(!overlay_vkms_obj->vaddr){
> + DRM_WARN("overlay palne vaddr is NULL");
s/palne/plane/
> + goto out;
> + }
> +
> + blend(vaddr_out, overlay_vkms_obj->vaddr, primary_crc, overlay_crc);
> +
> +out:
> + mutex_unlock(&overlay_vkms_obj->pages_lock);
> +}
> +
> static void compose_cursor(struct vkms_crc_data *cursor_crc,
> struct vkms_crc_data *primary_crc, void *vaddr_out)
> {
> @@ -131,7 +150,8 @@ static void compose_cursor(struct vkms_crc_data
> *cursor_crc,
> }
>
> static uint32_t _vkms_get_crc(struct vkms_crc_data *primary_crc,
> - struct vkms_crc_data *cursor_crc)
> + struct vkms_crc_data *cursor_crc,
> + struct vkms_crc_data *overlay_crc)
> {
> struct drm_framebuffer *fb = &primary_crc->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> @@ -154,6 +174,8 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
> *primary_crc,
> memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> mutex_unlock(&vkms_obj->pages_lock);
>
> + if (overlay_crc)
> + compose_overlay(overlay_crc, primary_crc, vaddr_out);
> if (cursor_crc)
> compose_cursor(cursor_crc, primary_crc, vaddr_out);
>
> @@ -184,6 +206,7 @@ void vkms_crc_work_handle(struct work_struct *work)
> output);
> struct vkms_crc_data *primary_crc = NULL;
> struct vkms_crc_data *cursor_crc = NULL;
> + struct vkms_crc_data *overlay_crc = NULL;
> struct drm_plane *plane;
> u32 crc32 = 0;
> u64 frame_start, frame_end;
> @@ -210,12 +233,17 @@ void vkms_crc_work_handle(struct work_struct *work)
>
> if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> primary_crc = crc_data;
> - else
> +
> + if (plane->type == DRM_PLANE_TYPE_CURSOR)
> cursor_crc = crc_data;
> +
> + if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> + overlay_crc = crc_data;
Maybe turn that into a switch() ?
> }
>
> - if (primary_crc)
> - crc32 = _vkms_get_crc(primary_crc, cursor_crc);
> + if (primary_crc){
> + crc32 = _vkms_get_crc(primary_crc, cursor_crc, overlay_crc);
> + }
>
> frame_end = drm_crtc_accurate_vblank_count(crtc);
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 738dd6206d85..b08ad6f95675 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -29,6 +29,10 @@ bool enable_cursor;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>
> +bool enable_overlay;
> +module_param_named(enable_overlay, enable_overlay, bool, 0444);
> +MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
> +
> static const struct file_operations vkms_driver_fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 81f1cfbeb936..81dceadfde62 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -20,6 +20,8 @@
>
> extern bool enable_cursor;
>
> +extern bool enable_overlay;
> +
> static const u32 vkms_formats[] = {
> DRM_FORMAT_XRGB,
> };
> @@ -28,6 +30,10
[Bug 109887] vega56 undervolting/overclocking voltage issues
https://bugs.freedesktop.org/show_bug.cgi?id=109887 --- Comment #3 from fin4...@hotmail.com --- You need to have a kernel command line parameter and c is used to commit changes. See: https://wiki.archlinux.org/index.php/AMDGPU#Overclocking -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: randr: Virtual monitor not present with MST display
On 2019-03-06 1:41 p.m., Paul Menzel wrote: > On 03/05/19 20:07, Alex Deucher wrote: >> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: > >>> Using the MST display Dell UP3214Q (two panels) with an AMD system, >>> the virtual monitor object is not created. GDM and Xfce consider both >>> panels as separate screens (`xrandr --listmonitors`). >>> >>> [0.00] Linux version 4.20.13.mx64.248 >>> (r...@holidayincambodia.molgen.mpg.de) (gcc version 7.3.0 (GCC)) #1 SMP Wed >>> Feb 27 14:10:55 CET 2019 >>> >>> [ 79.494297] [drm] DM_MST: stopping TM on aconnector: a8109331 >>> [id: 56] >>> [ 79.494362] [drm] DM_MST: Disabling connector: 776ea22b [id: 63] >>> [master: a8109331] >>> [ 79.494406] [drm] DM_MST: Disabling connector: 057ebdbb [id: 67] >>> [master: a8109331] >>> [ 79.781882] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last >>> cmd=0x201f0500 >>> [ 86.028806] [drm] DM_MST: starting TM on aconnector: a8109331 >>> [id: 56] >>> [ 86.053072] [drm] DM_MST: added connector: 1c9b49ed [id: 71] >>> [master: a8109331] >>> [ 86.108540] [drm] SADs count is: -2, don't need to read it >>> [ 86.386661] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >>> create stream for sink! >>> [ 87.237878] [drm] DM_MST: added connector: c3ffcbbb [id: 80] >>> [master: a8109331] >>> [ 87.293028] [drm] SADs count is: -2, don't need to read it >>> [ 206.993344] [drm] DM_MST: stopping TM on aconnector: a8109331 >>> [id: 56] >>> [ 206.993423] [drm] DM_MST: Disabling connector: 1c9b49ed [id: 71] >>> [master: a8109331] >>> [ 206.993456] [drm] DM_MST: Disabling connector: c3ffcbbb [id: 80] >>> [master: a8109331] >>> [ 207.548051] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >>> create stream for sink! >>> [ 207.603193] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >>> create stream for sink! >>> [ 207.762388] traps: xfdesktop[2225] general protection fault >>> ip:7f588981226c sp:7ffee65af370 error:0 in >>> libgobject-2.0.so.0.5800.1[7f58897da000+56000] >>> [ 210.320612] [drm] DM_MST: starting TM on aconnector: b456cd59 >>> [id: 62] >>> [ 210.343497] [drm] DM_MST: added connector: 735839d5 [id: 73] >>> [master: b456cd59] >>> [ 210.399168] [drm] SADs count is: -2, don't need to read it >>> [ 210.404454] [drm] DM_MST: added connector: cccb0c2d [id: 88] >>> [master: b456cd59] >>> [ 210.675589] [drm] SADs count is: -2, don't need to read it > > I didn’t provide the output of xrandr in my previous message. > > $ xrandr --listmonitors > Monitors: 2 > 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 > 1: +DisplayPort-10 1920/698x2160/392+1920+0 DisplayPort-10 > > Please find the X.Org X Server log attached. > >>> With an Intel system, the monitor object is shown. > > To clarify, the modesetting driver is used with the Intel hardware. Does this work better with the modesetting driver on the AMD system? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109834] No x86 libraries in new amdgpu-pro drivers
https://bugs.freedesktop.org/show_bug.cgi?id=109834 --- Comment #1 from fin4...@hotmail.com --- AMD has open source drivers for gaming. Amdgpu-pro is for CAD software etc. Steam games are for Debian based distributions, see system requirements. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
