[git pull] drm fixes for 4.18-rc8

Hi Linus, Nothing too major at this late stage, adv7511: reset fix vc4: scaling fix two atomic core fixes and one legacy core error handling fix. I had a bunch of driver fixes from hdlcd but I think I'll leave them for -next at this point. Thanks, Dave. drm-fixes-2018-08-03: adv7511 fix,

Re: [PATCH v2 15/15] drm/mediatek: fix connection from RDMA2 to DSI1

Hi, Stu: On Fri, 2018-08-03 at 11:11 +0800, Stu Hsieh wrote: > This patch fix connection from RDMA2 to DSI1 > > Signed-off-by: Stu Hsieh Reviewed-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH v2 14/15] drm/mediatek: update some variable name from ovl to comp

Hi, Stu: On Fri, 2018-08-03 at 11:11 +0800, Stu Hsieh wrote: > This patch update some variable name from ovl to comp > > Because RDMA would be first HW in ddp, the naming ovl > should be change to comp. > > Signed-off-by: Stu Hsieh Reviewed-by: CK Hu > --- >

Re: [PATCH v2 13/15] drm/mediatek: use layer_nr function to get layer number to init plane

Hi, Stu: On Fri, 2018-08-03 at 11:11 +0800, Stu Hsieh wrote: > This patch use layer_nr function to get layer number to init plane > > When plane init in crtc create, > it use the number of OVL layer to init plane. > That's OVL can read 4 memory address. > > For mt2712 third ddp, it use RDMA to

Re: [PATCH v2 12/15] drm/mediatek: add callback function to return RDMA layer number

Hi, Stu: On Fri, 2018-08-03 at 11:11 +0800, Stu Hsieh wrote: > This patch add callback function to return RDMA layer number > > Signed-off-by: Stu Hsieh > --- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git

Re: [PATCH v2 11/15] drm/mediatek: add callback function to return OVL layer number

Hi, Stu: On Fri, 2018-08-03 at 11:11 +0800, Stu Hsieh wrote: > This patch add callback function to return OVL layer number > > Signed-off-by: Stu Hsieh > --- > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git

Re: [PATCH v2 10/15] drm/mediatek: add function to get layer number for component

Hi, Stu: On Fri, 2018-08-03 at 11:11 +0800, Stu Hsieh wrote: > This patch add function to get layer number for component > > Signed-off-by: Stu Hsieh Reviewed-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git

Re: [PATCH v2 04/15] drm/mediatek: add connection from RDMA2 to DSI0

Hi, Stu: On Fri, 2018-08-03 at 11:10 +0800, Stu Hsieh wrote: > This patch add connection from RDMA2 to DSI0 > > Signed-off-by: Stu Hsieh Reviewed-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [PATCH v2 03/15] drm/mediatek: add connection from RDMA1 to DSI0

Hi, Stu: On Fri, 2018-08-03 at 11:10 +0800, Stu Hsieh wrote: > This patch add connection from RDMA1 to DSI0 > > Signed-off-by: Stu Hsieh Reviewed-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [PATCH v2 02/15] drm/mediatek: add connection from RDMA0 to DSI1

Hi, Stu: On Fri, 2018-08-03 at 11:10 +0800, Stu Hsieh wrote: > This patch add connection from RDMA0 to DSI1 > > Signed-off-by: Stu Hsieh Reviewed-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [PATCH v2 01/15] drm/mediatek: add connection from RDMA0 to DPI1

Hi, Stu: On Fri, 2018-08-03 at 11:10 +0800, Stu Hsieh wrote: > This patch add connection from RDMA0 to DPI1 > > Signed-off-by: Stu Hsieh Reviewed-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

[PATCH v2 13/15] drm/mediatek: use layer_nr function to get layer number to init plane

This patch use layer_nr function to get layer number to init plane When plane init in crtc create, it use the number of OVL layer to init plane. That's OVL can read 4 memory address. For mt2712 third ddp, it use RDMA to read memory. RDMA can read 1 memory address, so it just init one plane. For

[PATCH v2 02/15] drm/mediatek: add connection from RDMA0 to DSI1

This patch add connection from RDMA0 to DSI1 Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index 03e3628b5b0d..310d8482d5a0 100644 ---

[PATCH v2 11/15] drm/mediatek: add callback function to return OVL layer number

This patch add callback function to return OVL layer number Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c index

[PATCH v2 06/15] drm/mediatek: add memory mode for RDMA

This patch add memory mode for RDMA If use RDMA to read data from memory, it should set memory mode to RDMA Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c

[PATCH v2 12/15] drm/mediatek: add callback function to return RDMA layer number

This patch add callback function to return RDMA layer number Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c index

[PATCH v2 09/15] drm/mediatek: add YUYV/UYVY color format support for RDMA

This patch add YUYV/UYVY color format support for RDMA and transform matrix for YUYV/UYVY. Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c

[PATCH v2 15/15] drm/mediatek: fix connection from RDMA2 to DSI1

This patch fix connection from RDMA2 to DSI1 Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index 3239f22785fd..546b3e3b300b

[PATCH v2 14/15] drm/mediatek: update some variable name from ovl to comp

This patch update some variable name from ovl to comp Because RDMA would be first HW in ddp, the naming ovl should be change to comp. Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 26 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +- 2 files

[PATCH v2 10/15] drm/mediatek: add function to get layer number for component

This patch add function to get layer number for component Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h index

[PATCH v2 00/15] Add RDMA memory mode support for mediatek SOC MT2712

This patch series add RDMA memory mode support for mediatek SOC MT2712. MT2712 has three display data path, including three HW engine, two OVL and one RDMA. The RDMA used in third ddp and it need to be set memory mode, then RDMA could read data from memory and output to panel. Change in v2: -

[PATCH v2 01/15] drm/mediatek: add connection from RDMA0 to DPI1

This patch add connection from RDMA0 to DPI1 Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index 87e4191c250e..03e3628b5b0d 100644 ---

[PATCH v2 05/15] drm/mediatek: add RDMA memory mode for crtc created

This patch add RDMA memory mode for crtc created For mt2712, the third ddp use RDMA engine to read data from dram. Therefore, when crtc created, crtc need to decide using OVL or RDMA by ddp to read data from dram. If this ddp use RDMA, the crtc should set this RDMA which in the crtc using

[PATCH v2 03/15] drm/mediatek: add connection from RDMA1 to DSI0

This patch add connection from RDMA1 to DSI0 Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index 310d8482d5a0..31189fad8d4e 100644 ---

[PATCH v2 07/15] drm/mediatek: add layer config to set RDMA for plane setting

This patch add layer config to set RDMA for plane setting Layer config set the data address and pitch to RDMA from plane setting. Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 21 + 1 file changed, 21 insertions(+) diff --git

[PATCH v2 08/15] drm/mediatek: add RGB color format support for RDMA

This patch add RGB color format support for RDMA, including RGB565, RGB888, RGBA and ARGB. Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 41 1 file changed, 41 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c

[PATCH v2 04/15] drm/mediatek: add connection from RDMA2 to DSI0

This patch add connection from RDMA2 to DSI0 Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index 31189fad8d4e..3239f22785fd 100644 ---

[PATCH v5 2/2] dt-bindings: Add Truly NT35597 panel bindings

From: "abhin...@codeaurora.org" Add the device tree bindings for Truly NT35597 panel. This panel supports both single DSI and dual DSI. However, this patch series supports only dual DSI. Changes in v5: - None Signed-off-by: Abhinav Kumar ---

[PATCH v5 1/2] drm/panel: Add support for Truly NT35597 panel

From: "abhin...@codeaurora.org" Add support for Truly NT35597 panel used in MSM reference platforms. This panel supports both single DSI and dual DSI modes. However, this patch series adds support only for dual DSI mode. Changes in v5: - Added comments for the delays - Fix error messages and

[PATCH v5 2/2] dt-bindings: Add Truly NT35597 panel bindings

From: "abhin...@codeaurora.org" Add the device tree bindings for Truly NT35597 panel. This panel supports both single DSI and dual DSI. However, this patch series supports only dual DSI. Changes in v5: - None Signed-off-by: Abhinav Kumar ---

[PATCH v5 1/2] drm/panel: Add support for Truly NT35597 panel

From: "abhin...@codeaurora.org" Add support for Truly NT35597 panel used in MSM reference platforms. This panel supports both single DSI and dual DSI modes. However, this patch series adds support only for dual DSI mode. Changes in v5: - Added comments for the delays - Fix error messages and

Re: [PATCH] drm/i915/gvt: fix memory leak in intel_vgpu_ioctl()

On 2018.08.03 08:41:19 +0800, Yi Wang wrote: > The 'sparse' variable may leak when return in function > intel_vgpu_ioctl(), and this patch fixes this. > > Signed-off-by: Yi Wang > Reviewed-by: Jiang Biao > --- Looks fine to me, will queue this up. Thanks for the patch! >

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

Hello Christian, AMD guys, this one _together_ with these series [PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html on top of amd-staging-drm-next 53d5f1e4a6d9 freeze whole system (Intel Xeon X3470, RX580)

Re: [PATCH -next] drm/vkms: Fix the error handling in vkms_init()

On 08/02, Wei Yongjun wrote: > In the drm_vblank_init() error handling case, platform device > unregister is missing. This patch fix it. > > Fixes: 3a0709928b17 ("drm/vkms: Add vblank events simulated by hrtimers") > Signed-off-by: Wei Yongjun > --- > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > 1

Re: [PATCH v5 11/11] drm: rcar-du: Support interlaced video output through vsp1

Hi Kieran, Thank you for the patch. On Tuesday, 17 July 2018 23:35:53 EEST Kieran Bingham wrote: > From: Kieran Bingham > > Use the newly exposed VSP1 interface to enable interlaced frame support > through the VSP1 LIF pipelines. > > The DSMR register is updated to set the ODEV flag on

Re: [PATCH 1/3] soc/tegra: pmc: set IO pad power state and voltage via pinctrl fw

Hi Venkat, Thank you for the patch! Yet something to improve: [auto build test ERROR on tegra/for-next] [also build test ERROR on v4.18-rc7 next-20180802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH v5 10/11] media: vsp1: Support Interlaced display pipelines

Hi Kieran, Thank you for the patch. On Tuesday, 17 July 2018 23:35:52 EEST Kieran Bingham wrote: > From: Kieran Bingham > > Calculate the top and bottom fields for the interlaced frames and > utilise the extended display list command feature to implement the > auto-field operations. This

Re: [PATCH 1/3] soc/tegra: pmc: set IO pad power state and voltage via pinctrl fw

Hi Venkat, Thank you for the patch! Yet something to improve: [auto build test ERROR on tegra/for-next] [also build test ERROR on v4.18-rc7 next-20180802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[Bug 107152] GPU fault detected: 146 / VM_CONTEXT1_PROTECTION_FAULT / ring gfx timeout

https://bugs.freedesktop.org/show_bug.cgi?id=107152 --- Comment #7 from dwagner --- (In reply to Andrey Grodzovsky from comment #6) > dwanger, how quickly is this reproducible ? With the above video playback test (which I should refer to as the "Othan" test, because that is the name of the song

[Bug 107152] GPU fault detected: 146 / VM_CONTEXT1_PROTECTION_FAULT / ring gfx timeout

https://bugs.freedesktop.org/show_bug.cgi?id=107152 --- Comment #6 from Andrey Grodzovsky --- dwanger, how quickly is this reproducible ? A wild guess, what if you boot kernel with IOMMU disabled ? Add iommu=off to grub command line. -- You are receiving this mail because: You are the assignee

[Bug 199749] amdgpu on Ryzen 2400G freeze randomly

https://bugzilla.kernel.org/show_bug.cgi?id=199749 --- Comment #34 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- notsyncing, can you close this ticket then ? -- You are receiving this mail because: You are watching the assignee of the bug.

Re: [PATCH v4 8/8] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers

On Thu, 2018-08-02 at 21:40 +0200, Lukas Wunner wrote: > On Wed, Aug 01, 2018 at 05:14:58PM -0400, Lyude Paul wrote: > > We can't and don't need to try resuming the device from our hotplug > > handlers, but hotplug events are generally something we'd like to keep > > the device awake for whenever

Re: [PATCH v4 8/8] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers

On Wed, Aug 01, 2018 at 05:14:58PM -0400, Lyude Paul wrote: > We can't and don't need to try resuming the device from our hotplug > handlers, but hotplug events are generally something we'd like to keep > the device awake for whenever possible. So, grab a PM ref safely in our > hotplug handlers

Re: [PATCH v4 2/8] drm/nouveau: Enable polling even if we have runtime PM

oooh, thanks for pointing that out. I should have grepped for this function before doing that commit. There also appears to be another duplicate drm_kms_helper_poll_enable() in nouveau_vga.c which also looks equally suspecious as being useless. I will fix this up and also remove that other

Re: [PATCH v4 2/8] drm/nouveau: Enable polling even if we have runtime PM

On Wed, Aug 01, 2018 at 05:14:52PM -0400, Lyude Paul wrote: > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -592,10 +592,11 @@ nouveau_drm_load(struct drm_device *dev, unsigned long > flags) > pm_runtime_allow(dev->dev); >

Re: [PATCH v4 1/8] drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement

Hi Lyude, thanks a lot for your persistence in attacking these runtime PM issues in nouveau. v4 of this series looks very good overall. I only have comments on patches 1, 2 and 8. On this patch 1 it's merely a nit: On Wed, Aug 01, 2018 at 05:14:51PM -0400, Lyude Paul wrote: > ---

[Bug 68527] Planetary Annihilation Alpha: translation from TGSI failed !

https://bugs.freedesktop.org/show_bug.cgi?id=68527 --- Comment #22 from mirh --- (In reply to Bronson from comment #21) > Same issue here I belive: > https://bugs.freedesktop.org/show_bug.cgi?id=99349 Which was fixed in 17.3. Can anybody retest? -- You are receiving this mail because: You are

[Bug 107459] Atomically set gamma ramps are not applied until TTY switch

https://bugs.freedesktop.org/show_bug.cgi?id=107459 --- Comment #1 from Drew DeVault --- >When atomically setting gamma ramps on AMDGPU (specifically ), the changes >don't take effect until switching to another TTY and back again. Using the >legacy DRM interface works as expected.

[Bug 107459] Atomically set gamma ramps are not applied until TTY switch

https://bugs.freedesktop.org/show_bug.cgi?id=107459 Bug ID: 107459 Summary: Atomically set gamma ramps are not applied until TTY switch Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux

[Bug 102497] Fatal error during GPU init when using an aarch64 board

https://bugs.freedesktop.org/show_bug.cgi?id=102497 --- Comment #2 from Mikulas Patocka --- U-BOOT initializes the PCIe controller with 16MB window - it's too small for GPUs. You have to compile the EDK EFI firmware. You don't have to flash it, you can copy flash-image.bin to sdcard starting at

[Bug 107432] Periodic complete system lockup with Vega M and Kernel 4.18-rc6+

https://bugs.freedesktop.org/show_bug.cgi?id=107432 Robert Strube changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 107432] Periodic complete system lockup with Vega M and Kernel 4.18-rc6+

https://bugs.freedesktop.org/show_bug.cgi?id=107432 --- Comment #5 from Robert Strube --- So I've been conducting lots of additional investigation with both the vanilla kernel (4.18-rc7) and the kernel with your patch. I took more time to try to recreate the scenarios that cause the crash

[GIT PULL] tilcdc fixes for v4.19

Hi Dave, Please pull the tilcdc fixes for Linux v4.19. This fix has been pending for some while, because I was planning for a bigger clean up that would remove the need for this fix. But as it is the time for it - at least for v4.19 - is gone already so here is just this small fix. Best regards

[Bug 107456] WARNING: CPU: 11 PID: 1137 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:88 dm_dp_aux_transfer+0xa5/0xc0 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=107456 Bug ID: 107456 Summary: WARNING: CPU: 11 PID: 1137 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu _dm_mst_types.c:88 dm_dp_aux_transfer+0xa5/0xc0

Re: [PATCH] drm/msm/gpu: fix parameters in function msm_gpu_crashstate_capture

On Tue, Jul 31, 2018 at 10:45:32PM +0200, Anders Roxell wrote: > When CONFIG_DEV_COREDUMP isn't defined msm_gpu_crashstate_capture > doesn't pass the correct parameters. > drivers/gpu/drm/msm/msm_gpu.c: In function ‘recover_worker’: > drivers/gpu/drm/msm/msm_gpu.c:479:34: error: passing argument 2

Re: [PATCH v5 09/11] media: vsp1: Provide support for extended command pools

Hi Kieran, Thank you for the patch. On Tuesday, 17 July 2018 23:35:51 EEST Kieran Bingham wrote: > From: Kieran Bingham > > VSPD and VSP-DL devices can provide extended display lists supporting > extended command display list objects. > > These extended commands require their own dma memory

Re: [PATCH 2/2] drm/scheduler: stop setting rq to NULL

On 08/02/2018 02:43 AM, Nayan Deshmukh wrote: Hi Andrey, Good catch. I guess since both Christian and I were working on it parallelly we didn't catch this problem. If it is only causing a problem in push_job then we can handle it something like this:

Re: [PATCH v5 08/11] media: vsp1: Add support for extended display list headers

Hi Kieran, Thank you for the patch. On Tuesday, 17 July 2018 23:35:50 EEST Kieran Bingham wrote: > From: Kieran Bingham > > Extended display list headers allow pre and post command lists to be > executed by the VSP pipeline. This provides the base support for > features such as AUTO_FLD (for

[Bug 107454] BLENDER 2.8 principled BSDF shader and shadow are broken in EEVEE on mesa gallium r600g gpu

https://bugs.freedesktop.org/show_bug.cgi?id=107454 Bug ID: 107454 Summary: BLENDER 2.8 principled BSDF shader and shadow are broken in EEVEE on mesa gallium r600g gpu Product: Mesa Version: git Hardware: x86-64 (AMD64)

Re: [PATCH 2/2] drm/scheduler: stop setting rq to NULL

On 08/02/2018 02:47 AM, Nayan Deshmukh wrote: On Thu, Aug 2, 2018 at 12:12 PM Christian König > wrote: Am 02.08.2018 um 00:25 schrieb Andrey Grodzovsky: > Thinking again about this change and 53d5f1e drm/scheduler: move idle >

Re: [PATCH v3] gpu/drm/exynos: Convert drm_atomic_helper_suspend/resume()

Hi, On 2018-08-02 15:21, Souptick Joarder wrote: > convert drm_atomic_helper_suspend/resume() to use > drm_mode_config_helper_suspend/resume(). > > exynos_drm_fbdev_suspend/resume can be removed > as drm_mode_config_helper_suspend/resume has > implement the same in generic way. > > Remove

[Bug 105725] WARNING: CPU: 0 PID: 487 at drivers/gpu/drm/amd/amdgpu/../display /dc/gpio/gpio_base.c:64 dal_gpio_open_ex+0xc/0x30 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=105725 --- Comment #9 from Alex Deucher --- (In reply to Marc Thomas from comment #8) > After some testing/experimentation/and scouring the internet, I've found > that blacklisting modules gpio_amdpt (gpio-amdpt.ko) & pinctrl_amd > (pinctrl-amd.ko)

Re: [PATCH 1/3] soc/tegra: pmc: set IO pad power state and voltage via pinctrl fw

On 02/08/18 12:59, Venkat Reddy Talla wrote: > The IO pins of Tegra SoCs are grouped for common control > of IO interface like setting voltage signal levels and > power state of the interface. These groups are referred > to as IO pads.The power state and voltage control of IO pins > can be done

Re: [PATCH 0/2] add support rockchip px30 VOP

Thanks heiko, i am planing to send the next version patch :) 在 2018/8/2 18:40, Heiko Stuebner 写道: Hi Sandy, Am Dienstag, 26. Juni 2018, 10:53:33 CEST schrieb Sandy Huang: > The following patches add support rockchip px30 VOP, there are two seperate > VOP we call VOP big and VOP lite. > > vop

Re: [PATCH v1 11/15] drm/mediatek: add dummy buffer for RDMA memory mode

Hi, CK: On Wed, 2018-07-25 at 13:42 +0800, CK Hu wrote: > Hi, Stu: > > On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote: > > This patch add dummy buffer for RDMA memory mode > > > > When display power on, the drm frame work would modeset and > > set up the display HW. > > > > In this time,

Re: [PATCH v2] drm/mxsfb: Fix runtime PM for unpowering lcdif block

Hi Stefan, On Wed, 2018-08-01 at 12:00 +0200, Stefan Agner wrote: [...] > > @@ -307,14 +335,15 @@ void mxsfb_plane_atomic_update(struct > > mxsfb_drm_private *mxsfb, > > drm_crtc_send_vblank_event(crtc, event); > > } > > } > >

Re: [PATCH v1 14/15] drm/mediatek: fixed the error value for add DSI1 in mutex

Hi, CK: On Wed, 2018-07-25 at 13:10 +0800, CK Hu wrote: > Hi, Stu: > > > On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote: > > This patch fixed the error value for add DSI1 in mutex > > > > English is not my mother language, but should it be 'fix' rather than > 'fixed'? > > Regards, > CK >

Re: [PATCH v1 12/15] drm/mediatek: add layer number condition for RDMA to control plane

Hi, CK: On Wed, 2018-07-25 at 11:02 +0800, CK Hu wrote: > Hi, Stu: > > On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote: > > This patch add layer number condition for RDMA to control plane > > > > When plane init in crtc create, > > it use the number of OVL layer to init plane. > > That's OVL

Re: [PATCH v1 06/15] drm/mediatek: add memory mode for RDMA

Hi, CK: On Wed, 2018-07-25 at 10:40 +0800, CK Hu wrote: > Hi, Stu: > > On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote: > > This patch add memory mode for RDMA > > > > If use RDMA to read data from memory, it should set memory mode to RDMA > > > > Signed-off-by: Stu Hsieh > > --- > >

Re: [PATCH v1 00/15] Add RDMA memory mode support for mediatek SOC MT2712

Hi, CK: On Wed, 2018-07-25 at 09:39 +0800, CK Hu wrote: > Hi, Stu: > > It looks like the series is a bug fix of [1]. In [1], you create third > crtc but it does not work unless apply this series. So for all the > patches in this series, you should refer to [2] to add 'Fixes:' and > 'Cc:' in

[PATCH fix for 4.19 2/3] fbcon: Only defer console takeover if the current console driver is the dummycon

We rely on dummycon's output notifier mechanism to defer the takeover. If say vgacon is the current console driver then dummycon will never get used so its output notifier will also never get called and fbcon never takes over. This commit fixes this by only deferring the console takeover if the

[PATCH fix for 4.19 1/3] fbcon: Only allow FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER if fbdev is builtin

Having FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER with fbdev+fbcon being build as a module does not make much sense. Having FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER only when fbdev+fbcon are builtin was always the intention, hence the =y checks but they were checking the wrong option, fbcon is build as

[PATCH fix for 4.19 3/3] dummycon: Stop exporting dummycon_[un]register_output_notifier

Now that we only allow FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER when fbdev+fbcon are builtin exporting these is no longer necessary. Signed-off-by: Hans de Goede --- drivers/video/console/dummycon.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/video/console/dummycon.c

[PATCH fix for 4.19 0/3] fbcon: Fix VT switching being broken in combination with vgacon

Hi Bartlomiej, After backporting the deferred fbcon takeover patches to the 4.18 kernel for the upcoming Fedora 29 release, Fedora QA found a serious bug caused by the fbcon takeover support. When using classic (non EFI) boot on x86 and thus using vgacon, dummycon is not used, so the deferred

[PULL] drm-misc-next-fixes

Hi Dave, Two fixes for 4.19 here. For an oops on the DP CEC code and a memory leak on the vkms driver. Please pull. Regards, Gustavo drm-misc-next-fixes-2018-08-02: Fixes an oops on the DP CEC code and a memory leak on the vkms driver. The following changes since commit

Re: [PATCH v2 2/2] drm/vkms: Implement CRC debugfs API

Hi Haneen, On Thu, Aug 02, 2018 at 04:10:26AM +0300, Haneen Mohammed wrote: > This patch implement the necessary functions to compute and add CRCs > entries: > > - Implement the set_crc_source() callback. > - Compute CRC using crc32 on the visible part of the framebuffer. > - Use ordered

Re: [PATCH v2] drm/mxsfb: Fix runtime PM for unpowering lcdif block

On 02.08.2018 12:17, Philipp Zabel wrote: > On Tue, 2018-07-31 at 12:17 +, Leonard Crestez wrote: >> On Tue, 2018-07-31 at 13:54 +0200, Philipp Zabel wrote: >> > On Tue, 2018-07-17 at 13:48 +0300, Leonard Crestez wrote: >> > > Adding lcdif nodes to a power domain currently does work, it

[PATCH] drm/msm/dpu: enable cursor plane on dpu

Reserve DMA pipe for cursor plane and attach it to the crtc during the initialization. Signed-off-by: Sravanthi Kollukuduru --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53

[Bug 105725] WARNING: CPU: 0 PID: 487 at drivers/gpu/drm/amd/amdgpu/../display /dc/gpio/gpio_base.c:64 dal_gpio_open_ex+0xc/0x30 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=105725 --- Comment #8 from Marc Thomas --- After some testing/experimentation/and scouring the internet, I've found that blacklisting modules gpio_amdpt (gpio-amdpt.ko) & pinctrl_amd (pinctrl-amd.ko) greatly reduce the likelihood of the gpio_base.c:64

Re: [PATCH 0/2] add support rockchip px30 VOP

Hi Sandy, Am Dienstag, 26. Juni 2018, 10:53:33 CEST schrieb Sandy Huang: > The following patches add support rockchip px30 VOP, there are two seperate > VOP we call VOP big and VOP lite. > > vop big support win0,win1 and win2; > vop lit support win1(same with vop big win1); > > the max input

Re: [PATCH v2] drm/mxsfb: Fix runtime PM for unpowering lcdif block

On Tue, 2018-07-31 at 12:17 +, Leonard Crestez wrote: > On Tue, 2018-07-31 at 13:54 +0200, Philipp Zabel wrote: > > On Tue, 2018-07-17 at 13:48 +0300, Leonard Crestez wrote: > > > Adding lcdif nodes to a power domain currently does work, it results in > > > black/corrupted screens or hangs.

[PATCH] gpu: ipu-v3: default to id 0 on missing OF alias

This is better than storing -ENODEV in the id number. This fixes SoCs with only one IPU that don't specify an IPU alias in the device tree. Signed-off-by: Philipp Zabel --- drivers/gpu/ipu-v3/ipu-common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/ipu-v3/ipu-common.c

Re: [RFC 3/3] drm/omap: Add wide display support using multiple overlays

Hi Benoit, On 29/06/18 20:02, Benoit Parrot wrote: > In the case where we need to support wide-display using more than one > overlay to achieve the needed display resolution, we need to be able to > dynamically assign overlays to planes instead of having the overlays > being statically mapped to

[PATCH] gpu: ipu-v3: add support for XRGB32 and XBGR32 V4L2 pixel formats

These should be used instead of the ill-defined deprecated RGB32 and BGR32 V4L2 pixel formats. Signed-off-by: Philipp Zabel --- drivers/gpu/ipu-v3/ipu-common.c| 4 drivers/gpu/ipu-v3/ipu-cpmem.c | 8 drivers/gpu/ipu-v3/ipu-image-convert.c | 6 ++ 3 files

Re: [PATCH v3 04/14] gpu: ipu-v3: Fix U/V offset macros for planar 4:2:0

On Wed, 2018-08-01 at 12:12 -0700, Steve Longerbeam wrote: > The U and V offset macros for planar 4:2:0 (U_OFFSET, V_OFFSET, and > UV_OFFSET), are not correct. The height component to the offset was > calculated as: > > (pix->width * y / 4) > > But this does not produce correct offsets for odd

Re: [PATCH v3 05/14] gpu: ipu-v3: Allow negative offsets for interlaced scanning

On Wed, 2018-08-01 at 12:12 -0700, Steve Longerbeam wrote: > From: Philipp Zabel > > The IPU also supports interlaced buffers that start with the bottom field. > To achieve this, the the base address EBA has to be increased by a stride > length and the interlace offset ILO has to be set to the

Re: [PATCH v3 02/14] gpu: ipu-csi: Check for field type alternate

Hi Steve, On Wed, 2018-08-01 at 12:12 -0700, Steve Longerbeam wrote: > When the CSI is receiving from a bt.656 bus, include a check for > field type 'alternate' when determining whether to set CSI clock > mode to CCIR656_INTERLACED or CCIR656_PROGRESSIVE. > > Signed-off-by: Steve Longerbeam >

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #36 from Andrea Vettorello --- With recent development kernels from https://cgit.freedesktop.org/~agd5f/ (drm-next-4.19-wip, I think commit ddf74e79a54070f277ae520722d3bab7f7a6c67a) I can consistently complete cold/warm boot on my

Re: [PATCH v2] drm/imx: Convert drm_atomic_helper_suspend/resume()

Hi Souptick, On Wed, 2018-08-01 at 00:58 +0530, Souptick Joarder wrote: > convert drm_atomic_helper_suspend/resume() to use > drm_mode_config_helper_suspend/resume(). > > with this conversion, both the members of struct > imx_drm_device pipes and state will be no more > useful and it could be

Re: [RFC 1/3] drm/omap: Add ability to check if requested plane modes can be supported

Hi, On 29/06/18 20:02, Benoit Parrot wrote: > We currently assumed that an overlay has the same width and height as same _maximum_. > the overlay manager. This assumption is incorrect. On some variant the > overlay manager is twice the width that the overlay can handle. We need The maximum

[Bug 107432] Periodic complete system lockup with Vega M and Kernel 4.18-rc6+

https://bugs.freedesktop.org/show_bug.cgi?id=107432 Michel Dänzer changed: What|Removed |Added Attachment #140932|text/x-log |text/plain mime type|

[Bug 106846] RX480 with multiple HDMI ports shows monitor connected to unused port when using amdgpu.dc=1

https://bugs.freedesktop.org/show_bug.cgi?id=106846 --- Comment #6 from Tim Carr --- That fixed it. Everything seems good. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

On Wed, Aug 1, 2018 at 7:58 PM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Since we now deal with multiple rq we need to update all of them, not > just the current one. > > Signed-off-by: Christian König > Acked-by: Nayan Deshmukh > --- >

Re: [PATCH] staging/vboxvideo: Replace ttm_bo_unref with ttm_bo_put

Hi Am 02.08.2018 um 09:29 schrieb Greg KH: >> tbo = &((*bo)->bo); >> -ttm_bo_unref(); >> -if (!tbo) >> -*bo = NULL; >> +ttm_bo_put(tbo); > > This function is not in my tree, so it causes a build error. I guess > merge this through the drm tree? Yes. These functions

Re: [PATCH] staging/vboxvideo: Replace ttm_bo_unref with ttm_bo_put

On Tue, Jul 31, 2018 at 08:37:35AM +0200, Thomas Zimmermann wrote: > The function ttm_bo_put releases a reference to a TTM buffer object. The > function's name is more aligned to the Linux kernel convention of naming > ref-counting function _get and _put. > > A call to ttm_bo_unref takes the

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 1:40 PM, Florian Westphal wrote: > Dmitry Vyukov wrote: >> On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote: >> > Dmitry Vyukov wrote: >> >> Still can't grasp all details. >> >> There is state that we read without taking ct->ct_general.use ref >> >> first, namely

[PATCH 1/1] drm/dp: Add debufs support for DP dpcd log

Patch adds support for debugging DisplayPort : * All dpcd read/write transactions are logged * Logging done per AUX interface * Use following command to to list AUX transactions: bash # cat /sys/kernel/debug/drm_dp_aux/$AUXNAME @0x: 0x12 @0x0001: 0x14 @0x0002: 0xc4 @0x0003: 0x01 @0x0004:

Re: [PATCH 2/2] drm/scheduler: stop setting rq to NULL

Am 02.08.2018 um 08:47 schrieb Nayan Deshmukh: On Thu, Aug 2, 2018 at 12:12 PM Christian König > wrote: Am 02.08.2018 um 00:25 schrieb Andrey Grodzovsky: > Thinking again about this change and 53d5f1e drm/scheduler: move idle >

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

Dmitry Vyukov wrote: > Still can't grasp all details. > There is state that we read without taking ct->ct_general.use ref > first, namely ct->state and what's used by nf_ct_key_equal. > So let's say the entry we want to find is in the list, but > nf_conntrack_find finds a wrong entry earlier

Re: [PATCH 3/5] arm64: dts: renesas: r8a77995: Add LVDS support

> On August 1, 2018 at 12:35 PM jacopo mondi wrote: > > > Hi Ulrich, >I know this series needs to be re-spin when the D3/E3 LVDS PLL > support will be added, but since I need it for testing on D3 the LVDS > interface reset support, I noticed a small issue which I thought it is > worth

  1   2   >