dri-devel October 2018

dri-devel@lists.freedesktop.org

277 participants
1898 discussions

vc4: NULL pointer dereference in drm_client_dev_hotplug
by Stefan Wahren 03 Oct '18

03 Oct '18

Hi, Sergey Suloev already reported this NULL pointer dereference [1]. Now he was able to provide a Kernel config and i'm able to reproduce it with a Raspberry Pi 3 (arm64) and Linux 4.19-rc5. It seems like a invalid config [2] for vc4, but nevertheless the driver shouldn't crash at boot. [ 9.124598] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs directory [ 9.147667] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok [ 9.155184] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name! [ 9.166544] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [ 9.173840] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [ 9.181029] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) [ 9.188519] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4]) [ 9.195690] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 9.203523] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 9.215032] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 9.274785] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 9.290246] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 9.297464] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 9.304600] [drm] Driver supports precise vblank timestamp query. [ 9.323839] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 [ 9.382856] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup [drm_kms_helper]] *ERROR* Failed to set fbdev configuration [ 9.513495] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 [ 9.522507] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.clm_blob failed with error -2 [ 9.532939] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 9.545064] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f [ 10.404937] Unable to handle kernel paging request at virtual address 00330a656369768a [ 10.413081] Mem abort info: [ 10.415939] ESR = 0x96000004 [ 10.419082] Exception class = DABT (current EL), IL = 32 bits [ 10.425357] SET = 0, FnV = 0 [ 10.428533] EA = 0, S1PTW = 0 [ 10.431729] Data abort info: [ 10.434674] ISV = 0, ISS = 0x00000004 [ 10.438589] CM = 0, WnR = 0 [ 10.441620] [00330a656369768a] address between user and kernel address ranges [ 10.449087] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 10.454762] Modules linked in: brcmfmac vc4 drm_kms_helper cfg80211 drm rfkill smsc95xx brcmutil usbnet drm_panel_orientation_quirks raspberrypi_hwmon bcm2835_dma crc32_ce pwm_bcm2835 bcm2835_rng virt_dma rng_core i2c_bcm2835 ip_tables x_tables ipv6 [ 10.477296] CPU: 2 PID: 45 Comm: kworker/2:1 Not tainted 4.19.0-rc5 #3 [ 10.483934] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 10.489966] Workqueue: events output_poll_execute [drm_kms_helper] [ 10.496261] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 10.501321] pc : drm_client_dev_hotplug+0x5c/0xb0 [drm] [ 10.506776] lr : drm_client_dev_hotplug+0x38/0xb0 [drm] [ 10.512087] sp : ffff000008e83cd0 [ 10.515455] x29: ffff000008e83cd0 x28: 0000000000000000 [ 10.520859] x27: ffff000000ad1c60 x26: ffff800034207230 [ 10.526263] x25: 0000000000000001 x24: 0000000000000002 [ 10.531666] x23: ffff8000342070f8 x22: ffff0000009bd398 [ 10.537070] x21: ffff800034207118 x20: ffff800034207000 [ 10.542474] x19: ffff800035638800 x18: ffffffffffffffff [ 10.547877] x17: 0000000000000000 x16: 0000000000000000 [ 10.553281] x15: 0000000000000400 x14: 0000000000000400 [ 10.558685] x13: 0000000000000002 x12: 0000000000000000 [ 10.564088] x11: 0000000000000000 x10: 0000000000000000 [ 10.569492] x9 : 0000000000000001 x8 : 00000000ffffffff [ 10.574896] x7 : ffff8000373a52a0 x6 : ffff800033087500 [ 10.580298] x5 : ffff000008e83ba0 x4 : ffff8000373bdc20 [ 10.585701] x3 : ffff8000342070f8 x2 : ffff800035fb9a80 [ 10.591104] x1 : 30330a6563697672 x0 : ffff800035638800 [ 10.596515] Process kworker/2:1 (pid: 45, stack limit = 0x000000007e8924dc) [ 10.603590] Call trace: [ 10.606259] drm_client_dev_hotplug+0x5c/0xb0 [drm] [ 10.611303] drm_kms_helper_hotplug_event+0x30/0x40 [drm_kms_helper] [ 10.617849] output_poll_execute+0xc4/0x1e0 [drm_kms_helper] [ 10.623616] process_one_work+0x1c8/0x318 [ 10.627695] worker_thread+0x48/0x428 [ 10.631420] kthread+0xf8/0x128 [ 10.634615] ret_from_fork+0x10/0x18 [ 10.638255] Code: 54000220 f9401261 aa1303e0 b4000141 (f9400c21) [ 10.644456] ---[ end trace c75b4a4b0e141908 ]--- [1] - https://lists.freedesktop.org/archives/dri-devel/2018-September/188812.html [2] - https://github.com/anholt/linux/files/2429699/arm64_config.txt

6 16

[PATCH 00/13] drm/msm: Hook up the DRM gpu scheduler
by Sharat Masetty 03 Oct '18

03 Oct '18

This series is an effort to have the msm drm driver start using the DRM gpu scheduler for its general job scheduling needs. Immediate benefits to the msm drm driver include async fencing and improved driver performance. Testing is still under progress, but general GPU submissions, preemption, timeout, fault recovery and slumber all work fine with these changes when tested using my test apps. My workspace is based on ~4.18.rc6, so these changes should apply on tip relatively easily. Please review and share your valuable feedback :-). Note that I backported a change from Linus's 4.19.rc1 tree to handle jiffie wrapping. If it's not desirable, I will squash the last few changes of the series under drm/msm into one single commit. Matteo Croce (1): jiffies: add utility function to calculate delta in ms Sharat Masetty (12): drm/msm: Track GPU fences with idr drm/msm: Change msm_gpu_submit() API drm/msm: Save the ring name in the ring structure drm/msm: Change the name of the fence to hw_fence drm/msm: rearrange submit buffer objects clean up drm/msm: Use kzalloc for submit struct allocation drm/msm: Fix leak in submitqueue create drm/scheduler: set sched->thread to NULL in failure drm/msm: Use the DRM common Scheduler msm/drm: Remove unused code drm/scheduler: Add a timeout_start_notify function op drm/msm: Implement better timeout detection drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/Makefile | 3 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 - drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 29 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 + drivers/gpu/drm/msm/msm_drv.c | 3 +- drivers/gpu/drm/msm/msm_drv.h | 5 +- drivers/gpu/drm/msm/msm_fence.c | 52 ++--- drivers/gpu/drm/msm/msm_fence.h | 5 +- drivers/gpu/drm/msm/msm_gem.c | 44 +--- drivers/gpu/drm/msm/msm_gem.h | 10 +- drivers/gpu/drm/msm/msm_gem_submit.c | 170 +++++++++----- drivers/gpu/drm/msm/msm_gpu.c | 264 ++++------------------ drivers/gpu/drm/msm/msm_gpu.h | 11 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 17 +- drivers/gpu/drm/msm/msm_ringbuffer.h | 7 + drivers/gpu/drm/msm/msm_sched.c | 355 ++++++++++++++++++++++++++++++ drivers/gpu/drm/msm/msm_sched.h | 18 ++ drivers/gpu/drm/msm/msm_submitqueue.c | 16 +- drivers/gpu/drm/scheduler/gpu_scheduler.c | 22 +- include/drm/gpu_scheduler.h | 6 + include/linux/jiffies.h | 5 + 22 files changed, 662 insertions(+), 387 deletions(-) create mode 100644 drivers/gpu/drm/msm/msm_sched.c create mode 100644 drivers/gpu/drm/msm/msm_sched.h -- 1.9.1

3 21

[GIT PULL] mali-dp next
by Liviu Dudau 03 Oct '18

03 Oct '18

Hi Dave, These are the latest changes I have for Mali DP. Please note that due to drm-next lagging behind drm-fixes at this moment, the first two patches ("drm: mali-dp: Call drm_crtc_vblank_reset on device init" and "drm/malidp: Fix writeback in NV12") will be skipped if you backport v4.19-rc6 into drm-next before pulling this. Let me know if you prefer a pull request without those commits or something based on v4.19-rc6 instead of drm-next. Best regards, Liviu The following changes since commit 87c2ee740c07f1edae9eec8bc45cb9b32a68f323: Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-09-28 09:48:40 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/mali-dp for you to fetch changes up to 3dae1c0919d8c46710187df4fa1a43622289a1f5: drm/arm/malidp: Implemented the size validation for AFBC framebuffers (2018-10-02 12:12:19 +0100) ---------------------------------------------------------------- Alexandru Gheorghe (3): drm: mali-dp: Call drm_crtc_vblank_reset on device init drm/malidp: Fix writeback in NV12 drm/malidp: Fix smart layer when doing pm_suspend/resume Ayan Kumar Halder (1): drm/arm/malidp: Implemented the size validation for AFBC framebuffers Jamie Fox (1): drm/malidp: Enable MMU prefetch on Mali-DP650 Liviu Dudau (1): drm/arm/malidp: Validate rotations for compressed/uncompressed framebuffers for each layer Lowry Li (1): drm/mali-dp: Implement plane alpha and pixel blend on malidp drivers/gpu/drm/arm/malidp_crtc.c | 28 +-- drivers/gpu/drm/arm/malidp_drv.c | 129 +++++++++++++- drivers/gpu/drm/arm/malidp_drv.h | 8 + drivers/gpu/drm/arm/malidp_hw.c | 83 +++++++-- drivers/gpu/drm/arm/malidp_hw.h | 16 +- drivers/gpu/drm/arm/malidp_mw.c | 25 ++- drivers/gpu/drm/arm/malidp_planes.c | 347 +++++++++++++++++++++++++++++++----- drivers/gpu/drm/arm/malidp_regs.h | 13 ++ 8 files changed, 569 insertions(+), 80 deletions(-) -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯

1 0

[PATCH 2/2] drm/exynos: decon: Make pixel blend mode configurable
by Christoph Manszewski 03 Oct '18

03 Oct '18

Currently blend mode is set accordingly to pixel format. Add pixel blend mode property and make that configurable. Decon hardware doesn't support premultiplied mode, chose coverage as default. Tested on TM2 with Exynos 5433 CPU, on top of exynos-drm-next using modetest. Signed-off-by: Christoph Manszewski <c.manszewski(a)samsung.com> --- Currently, the driver exposes the "premultiplied" option for pixel blend mode property, and handles it as "coverage". This is due to the fact, that "premultiplied" mode is mandatory and is used as default. The question is - how to correctly deal with hardare that doesn't support premultiplied mode? drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 29 ++++++++++++++++++++++----- drivers/gpu/drm/exynos/regs-decon5433.h | 1 + 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c index dff540160199..15609c9f2fda 100644 --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c @@ -84,12 +84,13 @@ static const enum drm_plane_type decon_win_types[WINDOWS_NR] = { [CURSON_WIN] = DRM_PLANE_TYPE_CURSOR, }; + static const unsigned int capabilities[WINDOWS_NR] = { EXYNOS_DRM_PLANE_CAP_WIN_BLEND, - EXYNOS_DRM_PLANE_CAP_WIN_BLEND, - EXYNOS_DRM_PLANE_CAP_WIN_BLEND, - EXYNOS_DRM_PLANE_CAP_WIN_BLEND, - EXYNOS_DRM_PLANE_CAP_WIN_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND, }; static inline void decon_set_bits(struct decon_context *ctx, u32 reg, u32 mask, @@ -276,6 +277,24 @@ static void decon_win_set_bldmod(struct decon_context *ctx, unsigned int win, unsigned int alpha = state->base.alpha; u32 win_alpha = alpha >> 8; u32 val = 0; + unsigned int pixel_alpha; + + if (fb->format->has_alpha) + pixel_alpha = state->base.pixel_blend_mode; + else + pixel_alpha = DRM_MODE_BLEND_PIXEL_NONE; + + switch (pixel_alpha) { + case DRM_MODE_BLEND_PIXEL_NONE: + break; + case DRM_MODE_BLEND_COVERAGE: + default: + val |= WINCONx_ALPHA_SEL_F; + val |= WINCONx_BLD_PIX_F; + val |= WINCONx_ALPHA_MUL_F; + break; + } + decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_BLEND_MODE_MASK, val); if (alpha != DRM_BLEND_ALPHA_OPAQUE) { val = VIDOSD_Wx_ALPHA_R_F(win_alpha) | VIDOSD_Wx_ALPHA_G_F(win_alpha) | @@ -335,7 +354,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win, val |= WINCONx_BURSTLEN_8WORD; } - writel(val, ctx->addr + DECON_WINCONx(win)); + decon_set_bits(ctx, DECON_WINCONx(win), ~WINCONx_BLEND_MODE_MASK, val); } static void decon_shadow_protect(struct decon_context *ctx, bool protect) diff --git a/drivers/gpu/drm/exynos/regs-decon5433.h b/drivers/gpu/drm/exynos/regs-decon5433.h index f42d8f0adf5d..17b7324922c1 100644 --- a/drivers/gpu/drm/exynos/regs-decon5433.h +++ b/drivers/gpu/drm/exynos/regs-decon5433.h @@ -117,6 +117,7 @@ #define WINCONx_BPPMODE_16BPP_A4444 (0xe << 2) #define WINCONx_ALPHA_SEL_F (1 << 1) #define WINCONx_ENWIN_F (1 << 0) +#define WINCONx_BLEND_MODE_MASK (0xc2) /* SHADOWCON */ #define SHADOWCON_PROTECT_MASK GENMASK(14, 10) -- 2.7.4

1 0

[PATCH 1/2] drm/exynos: decon: Make plane alpha configurable
by Christoph Manszewski 03 Oct '18

03 Oct '18

The decon hardware supports variable plane alpha. Currently planes are opaque, make this configurable. Tested on TM2 with Exynos 5433 CPU, on top of exynos-drm-next. Signed-off-by: Christoph Manszewski <c.manszewski(a)samsung.com> --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 30 +++++++++++++++++++++++++++ drivers/gpu/drm/exynos/regs-decon5433.h | 4 ++++ 2 files changed, 34 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c index 94529aa82339..dff540160199 100644 --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c @@ -84,6 +84,14 @@ static const enum drm_plane_type decon_win_types[WINDOWS_NR] = { [CURSON_WIN] = DRM_PLANE_TYPE_CURSOR, }; +static const unsigned int capabilities[WINDOWS_NR] = { + EXYNOS_DRM_PLANE_CAP_WIN_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND, + EXYNOS_DRM_PLANE_CAP_WIN_BLEND, +}; + static inline void decon_set_bits(struct decon_context *ctx, u32 reg, u32 mask, u32 val) { @@ -259,6 +267,24 @@ static void decon_commit(struct exynos_drm_crtc *crtc) decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0); } +static void decon_win_set_bldmod(struct decon_context *ctx, unsigned int win, + struct drm_framebuffer *fb) +{ + struct exynos_drm_plane plane = ctx->planes[win]; + struct exynos_drm_plane_state *state = + to_exynos_plane_state(plane.base.state); + unsigned int alpha = state->base.alpha; + u32 win_alpha = alpha >> 8; + u32 val = 0; + + if (alpha != DRM_BLEND_ALPHA_OPAQUE) { + val = VIDOSD_Wx_ALPHA_R_F(win_alpha) | VIDOSD_Wx_ALPHA_G_F(win_alpha) | + VIDOSD_Wx_ALPHA_B_F(win_alpha); + decon_set_bits(ctx, DECON_VIDOSDxC(win), 0xffffff, val); + decon_set_bits(ctx, DECON_BLENDCON, BLEND_NEW, BLEND_NEW); + } +} + static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win, struct drm_framebuffer *fb) { @@ -267,6 +293,8 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win, val = readl(ctx->addr + DECON_WINCONx(win)); val &= WINCONx_ENWIN_F; + decon_win_set_bldmod(ctx, win, fb); + switch (fb->format->format) { case DRM_FORMAT_XRGB1555: val |= WINCONx_BPPMODE_16BPP_I1555; @@ -288,6 +316,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win, val |= WINCONx_BPPMODE_32BPP_A8888; val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F | WINCONx_ALPHA_SEL_F; val |= WINCONx_BURSTLEN_16WORD; + val |= WINCONx_ALPHA_MUL_F; break; } @@ -561,6 +590,7 @@ static int decon_bind(struct device *dev, struct device *master, void *data) ctx->configs[win].num_pixel_formats = ARRAY_SIZE(decon_formats); ctx->configs[win].zpos = win - ctx->first_win; ctx->configs[win].type = decon_win_types[win]; + ctx->configs[win].capabilities = capabilities[win]; ret = exynos_plane_init(drm_dev, &ctx->planes[win], win, &ctx->configs[win]); diff --git a/drivers/gpu/drm/exynos/regs-decon5433.h b/drivers/gpu/drm/exynos/regs-decon5433.h index 19ad9e47945e..f42d8f0adf5d 100644 --- a/drivers/gpu/drm/exynos/regs-decon5433.h +++ b/drivers/gpu/drm/exynos/regs-decon5433.h @@ -104,6 +104,7 @@ #define WINCONx_BURSTLEN_16WORD (0x0 << 10) #define WINCONx_BURSTLEN_8WORD (0x1 << 10) #define WINCONx_BURSTLEN_4WORD (0x2 << 10) +#define WINCONx_ALPHA_MUL_F (1 << 7) #define WINCONx_BLD_PIX_F (1 << 6) #define WINCONx_BPPMODE_MASK (0xf << 2) #define WINCONx_BPPMODE_16BPP_565 (0x5 << 2) @@ -206,4 +207,7 @@ #define CRCCTRL_CRCEN (0x1 << 0) #define CRCCTRL_MASK (0x7) +/* BLENDCON */ +#define BLEND_NEW (1 << 0) + #endif /* EXYNOS_REGS_DECON5433_H */ -- 2.7.4

1 0

[PATCH] drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
by Kai-Heng Feng 03 Oct '18

03 Oct '18

There's another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc instead of 8 bpc. Apply 6 bpc quirk for the panel to fix it. BugLink: https://bugs.launchpad.net/bugs/1794387 Cc: <stable(a)vger.kernel.org> # v4.8+ Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 3c9fc99648b7..1e2b9407c8d0 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -113,6 +113,9 @@ static const struct edid_quirk { /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */ { "AEO", 0, EDID_QUIRK_FORCE_6BPC }, + /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc panel */ + { "BOE", 0x78b, EDID_QUIRK_FORCE_6BPC }, + /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */ { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC }, -- 2.17.1

2 1

Access the intel graphic card via libdrm
by Horst Balthasar 03 Oct '18

03 Oct '18

Hallo, as a software developer at the company "imed medical" in Neu-Ulm" I am working with the intel graphics driver under Debian. The aim is to output continuous 2D images with the "libdrm" graphic library on the screen. We use the Intel i915 driver. Since I'm not so familiar with the Intel graphics driver (framebuffer, DRM) unter Debian, I would be verry happy about tips and examples to get familiar with this topic. I have already downloaded, compiled and installed the libdrm 2.4.94. I have also implemented the examples from 'modeset' and I am able to display a png file on the screen. But to process the images afterwards, we need access to the GPU, maybe GEM ??? Are there any examples or docs to help me get used it? Thank you very much. Bests regards, Horst Balthasar Horst Balthasar Software-Entwickler Medizintechnik -- imed medical GmbH Friedrichshafener Strasse 7 D-89079 Ulm Standort Neu-Ulm Marlene-Dietrich-Strasse 5 D-89231 Neu-Ulm Fon +49 (0)731 1411 179-6 Fax +49 (0)731 1411 6513 Zentrale +49 (0)731 1411 179-0 Web www.imed-medical.de Sitz der Gesellschaft: Ulm Württemberg | Registergericht Ulm | HRB 730620 | Geschäftsführer: Benedikt Schmalz, Stefan Schmalz-Conrad Diese E-Mail ist vertraulich und enthält gesetzlich geschützte Informationen. Wenn Sie NICHT der rechtmäßige Empfänger oder einer seiner Mitarbeiter sind, dürfen Sie den Inhalt WEDER lesen, kopieren, verbreiten NOCH nutzen. Sollten Sie diese E-Mail versehentlich erhalten haben, senden Sie sie bitte an uns zurück und löschen Sie sie anschließend dauerhaft. Vielen Dank.

2 1

[PATCH v5 00/11] drm/mediatek: support hdmi output for mt2701 and mt7623
by Bibby Hsieh 03 Oct '18

03 Oct '18

In order to support HDMI on mt2701, we have to make some modifications. 1) Add the HDMI driver. 2) Add the DPI driver. 3) Add a mechanism that config output component by dts. Change since v4: - move some change from patch9 to patch7 Change since v3: - Remove drm/mediatek: config component output by device node port patch, we will push another patches to flexibly config the component output. - fixup the return value - replace dpi->power_ctl and power_sta with reference count mechanism. - move the common function to mtk_hdmi_phy.c/h Changes since v2: - Fix the typo in commit message. - Remove const of reg_h_fre_con in the mtk_dpi_conf struct - Remove unused error log - Use lower casee for hex number - Use common API which defined in mtk_hdmi_phy.c to reduce code size - Implemet the enable/disable of phy_pll_ops the same as 8173 - Move the common header to mtk_hdmi_phy.h - Remove the including of debugfs.h NOTE: - add description about thecoponent output in the binding document in v4. Changes since v1: - Separate some patches to independent patch. - add DISP_REG_CONFIG_DSI_SEL and DISP_REG_CONFIG_DPI_SEL configuration in the condition of BLS&DPI0 connection. Changes since v0: - Correct some typos in commit message. - Fixup the build warning (tmp variable didn't be initialized) Bibby Hsieh (2): drm/mediatek: implement connection from BLS to DPI0 drm/mediatek: add a error return value when clock driver has been prepared chunhui dai (9): drm/mediatek: add refcount for DPI power on/off drm/mediatek: move hardware register to node data drm/mediatek: adjust EDGE to match clock and data drm/mediatek: add clock factor for different IC drm/mediatek: convert dpi driver to use drm_of_find_panel_or_bridge drm/mediatek: add dpi driver for mt2701 and mt7623 drm/mediatek: separate hdmi phy to different file drm/mediatek: add support for SPDIF audio in HDMI drm/mediatek: add hdmi driver for MT2701 and MT7623 drivers/gpu/drm/mediatek/Makefile | 5 +- drivers/gpu/drm/mediatek/mtk_dpi.c | 131 ++++++++------ drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 2 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 + drivers/gpu/drm/mediatek/mtk_hdmi.c | 15 +- drivers/gpu/drm/mediatek/mtk_hdmi.h | 2 +- drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 235 +++++++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 60 +++++++ drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 212 ++++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 226 +----------------------- 12 files changed, 627 insertions(+), 279 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c -- 2.12.5.2.gbdf23ab

2 13

[Bug 108037] Turning monitors off and on again makes the kernel panic and system freeze
by bugzilla-daemon＠freedesktop.org 03 Oct '18

03 Oct '18

https://bugs.freedesktop.org/show_bug.cgi?id=108037 --- Comment #8 from Öyvind Saether <oyvinds(a)everdot.org> --- https://bugzilla.redhat.com/show_bug.cgi?id=1618950 looks like a similar error https://bugzilla.redhat.com/attachment.cgi?id=1476793 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 107857] [apitrace] GPU hang on VEGA10
by bugzilla-daemon＠freedesktop.org 02 Oct '18

02 Oct '18

https://bugs.freedesktop.org/show_bug.cgi?id=107857 Bug ID: 107857 Summary: [apitrace] GPU hang on VEGA10 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: joseph.kucia(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 141472 --> https://bugs.freedesktop.org/attachment.cgi?id=141472&action=edit apitrace This can be reproduced reliably using the attached apitrace. OpenGL renderer string: Radeon RX Vega (VEGA10, DRM 3.23.0, 4.15.5-gentoo, LLVM 6.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.0-devel (git-1c7a2433b2) -- You are receiving this mail because: You are the assignee for the bug.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2018