Re: [PATCH v2] backlight: pwm_bl: Fix uninitialized variable

On Mon, Jul 23, 2018 at 08:23:43AM +0100, Lee Jones wrote: > On Thu, 19 Jul 2018, Daniel Thompson wrote: > > > Currently, if the DT does not define num-interpolated-steps then > > num_steps is undefined and the interpolation code will deploy randomly. > > Fix this. > > > > Additionally fix a smal

Re: [PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}

2018년 06월 11일 21:24에 Marek Szyprowski 이(가) 쓴 글: > The virtual Exynos DRM device has no runtime PM enabled, so checking > for its runtime suspended state is useless. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++--- > 1 file changed, 3 insertions(+)

[PATCH v3] backlight: pwm_bl: Fix uninitialized variable

Currently, if the DT does not define num-interpolated-steps then num_steps is undefined and the interpolation code will deploy randomly. Fix with a simple initialize to zero. Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between brightness-levels") Reported-by: Marcel Ziswiler Sig

Re: [PATCH v2] gpu: drm: virtio: code cleanup

On Tue, Jul 17, 2018 at 5:04 PM, Souptick Joarder wrote: > On Tue, Jul 3, 2018 at 9:03 PM, Souptick Joarder wrote: >> The fault handler code is commented since v4.2. >> If there is no plan to enable the fault handler >> code in future, we can remove this dead code. >> >> Signed-off-by: Souptick J

[PATCH] gpu/drm/vkms: Use new return type vm_fault_t

Use new return type vm_fault_t for fault handler. Signed-off-by: Souptick Joarder --- drivers/gpu/drm/vkms/vkms_drv.h | 2 +- drivers/gpu/drm/vkms/vkms_gem.c | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.

Re: [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: > On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: >> >>> data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function >>> ‘gntdev_ioctl_dmabuf_exp_from_refs’: >>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning: >

Re: [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/20/2018 05:08 PM, Boris Ostrovsky wrote: On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There

[PATCH] gpu: drm: amdgpu: Replace mdelay with msleep in cik_pcie_gen3_enable()

cik_pcie_gen3_enable() is only called by cik_common_hw_init(), which is never called in atomic context. cik_pcie_gen3_enable() calls mdelay() to busily wait, which is not necessary. mdelay() can be replaced with msleep(). This is found by a static analysis tool named DCNS written by myself. Signe

Re: [RFC PATCH] drm/atomic: add ASYNC_UPDATE flag to the Atomic IOCTL.

Hi Ville, On 06/07/18 12:54, Gustavo Padovan wrote: > Hi Ville, > > On Thu, 2018-06-28 at 16:35 +0300, Ville Syrjälä wrote: >> On Wed, Jun 27, 2018 at 11:25:06PM +0200, Enric Balletbo i Serra >> wrote: >>> From: Gustavo Padovan >>> >>> This flag tells core to jump ahead the queued update if the

Re: etnaviv oops on imx6dl/2G, works fine on imx6s/512M

On 23.7.2018 12:13, Lucas Stach wrote: Hi Michal, Am Mittwoch, den 18.07.2018, 14:29 +0200 schrieb Michal Vokáč: Ahoj, I encountered an error in etnaviv driver on one of my two very similar SBCs. They have the same board design but slightly different HW configuration. SW configuration/setup is

Re: [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 06:22 PM, Boris Ostrovsky wrote: On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function ‘gntdev_ioctl_dmabuf_exp_from_refs’: /data/upstream/linux-xen/drivers/xen

Re: [RFC RESEND PATCH] drm/rockchip: update cursors asynchronously through atomic.

Hi Enric, On 07/23/2018 11:36 AM, Sean Paul wrote: On Wed, Jun 27, 2018 at 11:14:47PM +0200, Enric Balletbo i Serra wrote: Add support to async updates of cursors by using the new atomic interface for that. Signed-off-by: Enric Balletbo i Serra LGTM. Given rockchip hasn't weighed in on the

Re: [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: On 07/20/2018 05:08 PM, Boris Ostrovsky wrote: On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux

[PATCH] drm/msm: Replace PTR_RET with PTR_ERR_OR_ZERO

PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead. Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c in

[PATCH] drm/amdgpu/pm: Fix potential Spectre v1

idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state() warn: potential spectre issue 'data.states' Fi

Re: [PATCH] drm/tegra: hdmi: probe deferral error reporting

On July 23, 2018 10:49:15 PM GMT+02:00, Lucas Stach wrote: >Am Freitag, den 20.07.2018, 09:55 +0200 schrieb Marcel Ziswiler: >> From: Marcel Ziswiler >> >> Actually report the error code from devm_regulator_get() which may as >> well just be a probe deferral. > >This is still noisy, so while y

Re: [PATCH 06/10] drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic

Hi Alexandru, On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote: > Signed-off-by: Alexandru Gheorghe > --- > drivers/gpu/drm/imx/ipuv3-plane.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c > b/drivers/gpu/drm/imx/ip

Re: [PATCH v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"

Hi, 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글: > When adding support for peripheral out bridges, the "bridge" name > becomes imprecise as it refers to a different device than the > "out_bridge". Could you give me more details? I'm afriad that I don't understand what you say. And in case of Exy

Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset

Hi Alexandru, On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote: > There are a lot of drivers that subclass drm_plane_state, all of them > duplicate the code that links toghether the plane with plane_state. > > On top of that, drivers that enable core properties also have to > duplicate

Re: [PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}

Hi Inki, On 2018-07-24 09:12, Inki Dae wrote: > 2018년 06월 11일 21:24에 Marek Szyprowski 이(가) 쓴 글: >> The virtual Exynos DRM device has no runtime PM enabled, so checking >> for its runtime suspended state is useless. >> >> Signed-off-by: Marek Szyprowski >> --- >> drivers/gpu/drm/exynos/exynos_dr

[Bug 200633] [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.

https://bugzilla.kernel.org/show_bug.cgi?id=200633 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- Please attach the dmesg output and Xorg log file corresponding to the problem. amdgpu.dc=0 on the kernel command line might serve as a workaround for the time being. -- You are receivin

Re: [PATCH 06/10] drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic

On Tue, 2018-07-24 at 09:49 +0200, Philipp Zabel wrote: > Hi Alexandru, > > On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote: > > Signed-off-by: Alexandru Gheorghe > > --- > > drivers/gpu/drm/imx/ipuv3-plane.c | 8 +++- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > >

Re: [PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}

2018년 07월 24일 16:49에 Marek Szyprowski 이(가) 쓴 글: > Hi Inki, > > On 2018-07-24 09:12, Inki Dae wrote: >> 2018년 06월 11일 21:24에 Marek Szyprowski 이(가) 쓴 글: >>> The virtual Exynos DRM device has no runtime PM enabled, so checking >>> for its runtime suspended state is useless. >>> >>> Signed-off-by: M

[Bug 106441] Totem video playback stuttering and graphical artifacts

https://bugs.freedesktop.org/show_bug.cgi?id=106441 Michel Dänzer changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW

Re: [PATCH v3 3/9] drm/exynos: enable out_bridge in exynos_dsi_enable()

Hi, 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글: > As the out bridge will not be enabled directly by the framework, > it should be enabled by DSI. Exynos_dsi_enable() should handle a case, > when there is an out_bridge connected as a DSI peripheral. > > Signed-off-by: Maciej Purski > --- > driv

Re: [PATCH v3 2/9] drm/exynos: move connector creation to attach callback

Hi, 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글: > The current implementation assumes that the only possible peripheral > device for DSIM is a panel. Using an output bridge child device > should also be possible. > > If an output bridge is available, don't create a new connector. > Instead, call

Re: [PATCH v3 2/9] drm/exynos: move connector creation to attach callback

2018년 07월 24일 17:04에 Inki Dae 이(가) 쓴 글: > Hi, > > 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글: >> The current implementation assumes that the only possible peripheral >> device for DSIM is a panel. Using an output bridge child device >> should also be possible. >> >> If an output bridge is avail

Re: [PATCH 09/10] drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic

Hi Maxime, On Tue, Jul 24, 2018 at 08:57:20AM +0200, Maxime Ripard wrote: > On Fri, Jul 20, 2018 at 10:15:08PM +0100, Alexandru Gheorghe wrote: > > Signed-off-by: Alexandru Gheorghe > > --- > > drivers/gpu/drm/vc4/vc4_plane.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > >

Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset

On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote: > Hi Alexandru, > > On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote: > > There are a lot of drivers that subclass drm_plane_state, all of them > > duplicate the code that links toghether the plane with plane_state. > > > >

Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset

On Tue, 24 Jul 2018 09:14:02 +0100 Alexandru-Cosmin Gheorghe wrote: > On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote: > > Hi Alexandru, > > > > On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote: > > > There are a lot of drivers that subclass drm_plane_state, all of the

[PATCH v1 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 | 20 1 file changed, 20 insertions(+) diff --git a/drivers/gpu/drm/media

[PATCH v1 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 | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediate

[PATCH v1 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. Stu Hsieh (15): d

[PATCH v1 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 --- a/

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

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 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 com

[PATCH v1 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 --- a/

[PATCH v1 10/15] drm/mediatek: add drm_device in RDMA for mamory mode to reaquest buffer

If RDMA want to request gem buffer, it need to save the drm device. Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c index 49edbae50167

[PATCH v1 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 v1 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 memory

[PATCH v1 13/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 ch

[PATCH v1 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 --- a/

[PATCH v1 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 --- a/

[PATCH v1 15/15] drm/mediatek: fixed connection from RDMA2 to DSI1

This patch fixed 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 ac047fdb1a2b..66a27b6a7583

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

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, the RDMA would start wroking and read the data from memory. But, user space not send the data to drm yet. For this case, if user space not send data t

[PATCH v1 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 | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dis

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

This patch fixed the error value for add DSI1 in mutex 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..ac04

[RFC] drm: Allow DRM_IOCTL_MODE_MAP_DUMB for render nodes

From: Tomasz Figa There is no particular reason to prevent userspace for using this IOCTL, considering that it already has access to other, platform-specific IOCTLs. This patch makes is possible to have the same userspace code work regardless on the underlying platform, which significantly simpli

Re: [PATCH 03/10] drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying the logic

On Fri, Jul 20, 2018 at 10:15:02PM +0100, Alexandru Gheorghe wrote: With a more detailed commit message: Acked-by: Liviu Dudau > Signed-off-by: Alexandru Gheorghe > --- > drivers/gpu/drm/arm/malidp_planes.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drive

[Bug 107324] Radeon driver fails to install with modprobe: ERROR: could not insert 'radeon': Invalid argument

https://bugs.freedesktop.org/show_bug.cgi?id=107324 --- Comment #12 from jamesstewartmil...@gmail.com --- Is there any way to selectively swap out that portion of the driver for the inoffensive parts of code for the imac (and perhaps other problematic models) that I have? Is there any point in me

[Bug 107328] radeon_gart_table_vram_pin takes 473 ms during ACPI S3 resume

https://bugs.freedesktop.org/show_bug.cgi?id=107328 Paul Menzel changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #2 from Paul Menzel

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #36 from jian-h...@endlessm.com --- Created attachment 140806 --> https://bugs.freedesktop.org/attachment.cgi?id=140806&action=edit dmesg of 4.18.0-rc6 Tested with Linux 4.18.0-rc6 kernel. It seems the amdgpu module could be loaded

Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset

On Tue, Jul 24, 2018 at 10:16:56AM +0200, Boris Brezillon wrote: > On Tue, 24 Jul 2018 09:14:02 +0100 > Alexandru-Cosmin Gheorghe wrote: > > > On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote: > > > Hi Alexandru, > > > > > > On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrot

[Bug 107337] [CI][DRMTIP] igt@kms_3d - fail - Failed assertion: debugfs_fd != -1 / Last errno: 2, No such file or directory

https://bugs.freedesktop.org/show_bug.cgi?id=107337 Chris Wilson changed: What|Removed |Added Resolution|--- |FIXED Component|DRM/Intel

Re: [PATCH RESEND 1/2] drm/msm: call drm_atomic_helper_suspend() and drm_atomic_helper_resume()

On Tue, Jul 24, 2018 at 3:24 AM, Daniel Mack wrote: > To make suspend and resume work on msm8916 platforms, call into the generic > helpers and preserve the state across suspends. > > Signed-off-by: Daniel Mack > --- > I've sent these two small patches twice already in May, but I haven't > gotten

[Bug 106707] [CI] igt@gem_exec_schedule@deep-* - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0

https://bugs.freedesktop.org/show_bug.cgi?id=106707 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [PATCH] drm/sun4i: Use (struct drm_format_info) fields to determine if a format is yuv and multi planar or not.

On Mon, Jul 23, 2018 at 09:57:00AM +0100, Ayan Kumar Halder wrote: > We do not need sun4i_backend_format_is_packed_yuv422() / > sun4i_backend_format_is_planar_yuv() to determine if the format is yuv multi > planar > or not. (struct drm_format_info *)->is_yuv tells if the format is yuv or not. > An

Re: [PATCH v5 0/7] drm: add simpledrm driver

Hey On request of Noralf, I picked up the patches and prepared v5. Works fine with Xorg, if configured according to: https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html If anyone knows how to make Xorg pick it up dynamically without such a static configuration, plea

Re: [PATCH v2 00/18] Allwinner R40 HDMI refactoring

On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote: > Hi Maxime, > > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard napisal(a): > > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote: > > > This series fixes several issues found in R40 HDMI patch series after >

Re: [PATCH 09/10] drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic

On Tue, Jul 24, 2018 at 09:11:21AM +0100, Alexandru-Cosmin Gheorghe wrote: > Hi Maxime, > > On Tue, Jul 24, 2018 at 08:57:20AM +0200, Maxime Ripard wrote: > > On Fri, Jul 20, 2018 at 10:15:08PM +0100, Alexandru Gheorghe wrote: > > > Signed-off-by: Alexandru Gheorghe > > > --- > > > drivers/gpu/d

[Bug 107328] radeon_gart_table_vram_pin takes 473 ms during ACPI S3 resume

https://bugs.freedesktop.org/show_bug.cgi?id=107328 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Christian

[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #33 from Alex Smith --- We've had several user reports of this through our support, and reproduced it internally as well (on a 270X, which is our officially supported minimum spec). Seems to be specific to SI cards. Given that this h

[PATCH v2] drm/atomic: Check old_plane_state->crtc in drm_atomic_helper_async_check()

Async plane update is supposed to work only when updating the FB or FB position of an already enabled plane. That does not apply to requests where the plane was previously disabled or assigned to a different CTRC. Check old_plane_state->crtc value to make sure async plane update is allowed. Fixes

[PATCH v2] drm/atomic: Initialize variables in drm_atomic_helper_async_check() to make gcc happy

drm_atomic_helper_async_check() declares the plane, old_plane_state and new_plane_state variables to iterate over all planes of the atomic state and make sure only one plane is enabled. Unfortunately gcc is not smart enough to figure out that the check on n_planes is enough to guarantee that plane

[PATCH] drm/vc4: Reset ->{x, y}_scaling[1] when dealing with uniplanar formats

This is needed to ensure ->is_unity is correct when the plane was previously configured to output a multi-planar format with scaling enabled, and is then being reconfigured to output a uniplanar format. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Cc: Signed-off-by: Boris Brezillo

Re: [RFC PATCHv2 1/9] drm: Add support for extracting sync signal drive edge from videomode

Hi Tomi, Thank you for the patch. On Monday, 18 June 2018 16:22:34 EEST Tomi Valkeinen wrote: > From: Peter Ujfalusi > > The sync in some panels needs to be driven by different edge of the pixel > clock compared to data. This is reflected by the > DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in videmode f

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Fri 20-07-18 17:09:02, Andrew Morton wrote: [...] > - Undocumented return value. > > - comment "failed to reap part..." is misleading - sounds like it's > referring to something which happened in the past, is in fact > referring to something which might happen in the future. > > - fails to

Re: [RFC PATCHv2 2/9] dt-bindings: display/ti: add k2g-dss bindings

Hi Tomi, Thank you for the patch. On Monday, 18 June 2018 16:22:35 EEST Tomi Valkeinen wrote: > Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS > is quite simple, with a single plane and a single output. > > Signed-off-by: Tomi Valkeinen > Cc: devicet...@vger.kernel.org

Re: [PATCH] fbdev: Distinguish between interlaced and progressive modes

On Wednesday, July 04, 2018 09:08:48 PM Fredrik Noring wrote: > Hi Bartlomiej, > > > > With this change fb_find_mode can match interlaced and progressive > > > modes equally well, and distinguish between for example 1920x1080i > > > and 1920x1080p. > > > > > > Signed-off-by: Fredrik Noring > >

Re: [PATCH v2 1/2] dt-bindings: display: add devicetree bindings for pxa300-gcu

On Wednesday, July 04, 2018 09:35:01 PM Daniel Mack wrote: > This patch adds the binding documentation for the pxa300 gcu. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics _

Re: [PATCH v2 2/2] video: fbdev: pxa3xx_gcu: add devicetree bindings

On Wednesday, July 04, 2018 09:35:02 PM Daniel Mack wrote: > Add a device tree match table for this hardware graphics acceleration > driver so it can be used by pxa3xx boards booted with a devicetree. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zoln

Re: [PATCH 2/4] video: fbdev: pxafb: switch to devm_* API

On Sunday, June 24, 2018 05:38:15 PM Daniel Mack wrote: > This helps us clean up the probe() and remove() implementations. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics _

Re: [PATCH 1/4] video: fbdev: pxafb: clear allocated memory for video modes

On Sunday, June 24, 2018 05:38:14 PM Daniel Mack wrote: > When parsing the video modes from DT properties, make sure to zero out > memory before using it. This is important because not all fields in the mode > struct are explicitly initialized, even though they are used later on. > > Fixes: 420a48

Re: [PATCH 3/4] video: fbdev: pxafb: handle errors from pxafb_init_fbinfo() correctly

On Sunday, June 24, 2018 05:38:16 PM Daniel Mack wrote: > pxafb_init_fbinfo() can not only report errors caused by failed > allocations but also when the clock can't be found. > > To fix this, return an error pointer instead of NULL in case of errors, > and up-chain the result. > > Signed-off-by:

Re: [PATCH 4/4] video: fbdev: pxafb: Add support for lcd-supply regulator

On Sunday, June 24, 2018 05:38:17 PM Daniel Mack wrote: > Optionally obtain a lcd-supply regulator during probe and use it in > __pxafb_lcd_power() to switch the power supply of LCD panels. > > This helps boards booted from DT to control such voltages without > callbacks. > > Signed-off-by: Danie

Re: [PATCH 1/4] video: fbdev: pxafb: clear allocated memory for video modes

On Monday, July 09, 2018 07:12:50 AM Daniel Mack wrote: > Hi Bartlomiej, Hi, > Should I resend with Robert's Reviewed-bys again? I'd like to get this > merged for 4.19 if possible. No need for resend, I added Robert's tags while applying your patches. Best regards, -- Bartlomiej Zolnierkiewicz

Re: [PATCH libdrm] tests/modetest: Add modetest_atomic tool

2018-07-23 18:30 GMT+02:00 Eric Engestrom : > On Friday, 2018-07-20 13:33:29 +0200, Benjamin Gaignard wrote: >> This is a modetest like tool but using atomic API. >> >> With modetest_atomic it is mandatory to specify a mode ("-s") >> and a plane ("-P") to display a pattern on screen. >> >> "-v" doe

Re: [PATCH] video: fbdev: fsl-diu-fb: Remove VLA usage

On Saturday, June 30, 2018 10:59:15 AM Timur Tabi wrote: > On 6/29/18 1:46 PM, Kees Cook wrote: > > In the quest to remove all stack VLA usage from the kernel[1], this moves > > the buffer off the stack (since it could be as much as 1024 bytes), and > > uses a new area in the cursor data structure.

Re: [PATCH v2 fbdev-for-next 1/2] fbcon: introduce for_each_registered_fb() helper

On Saturday, June 30, 2018 03:29:49 PM Yisheng Xie wrote: > Following pattern is often used: > > for (i = 0; i < FB_MAX; i++) { > if (registered_fb[i]) { > ... > } > } > > Therefore, as Andy's suggestion, for_each_registered_fb() helper can > be introduced to mak

Re: [PATCH v2 fbdev-for-next 2/2] fbdev: fix typo in comment

On Saturday, June 30, 2018 03:30:48 PM Yisheng Xie wrote: > change beeng to being and occured to occurred. > > Signed-off-by: Yisheng Xie Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics _

Re: [PATCH] video/console/vgacon: Print big fat warning with nomodeset

On Monday, July 02, 2018 05:04:40 PM Lyude Paul wrote: > It's been a pretty good while since kernel modesetting was introduced. > It has almost entirely replaced previous solutions which required > userspace modesetting, and I can't even recall any drivers off the top > of my head for modern day ha

Re: [PATCH] video: fbdev: metronomefb: fix some off by one bugs

On Tuesday, July 03, 2018 03:28:13 PM Dan Carpenter wrote: > The "mem" buffer has "size" bytes. The ">" should be ">=" to prevent > reading one character beyond the end of the array. > > Signed-off-by: Dan Carpenter Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Sams

[RFC 0/3] Add Colorspace connector property interface

This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scen

[RFC 2/3] drm/i915: Attach colorspace property and enable modeset

This patch attaches the colorspace connector property to the hdmi connector. Based on colorspace change, modeset will be triggered to switch to new colorspace. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 3 +++ 2 files changed,

[RFC 1/3] drm: Add colorspace property

This patch adds a colorspace property, enabling userspace to switch to various supported colorspaces. This will help enable BT2020 along with other colorspaces. Signed-off-by: Uma Shankar --- drivers/gpu/drm/drm_atomic.c| 4 drivers/gpu/drm/drm_connector.c | 31

[RFC 3/3] drm/i915: Set colorspace by enabling Infoframe

Based on colorspace property value create an infoframe with appropriate colorspace. This can be used to send an infoframe packet with proper colorspace value set which will help to enable wider color gamut like BT2020 on sink. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdmi.c | 2

Re: [PATCH 00/10] Add helper for plane reset

On 2018-07-20 05:14 PM, Alexandru Gheorghe wrote: > Drivers that subclass drm_plane need to copy the logic for linking the > drm_plane with its state and to initialize core properties to their > default values. E.g (alpha and rotation) > > Having a helper to reset the plane_state makes sense becau

[Bug 107309] libGL error: MESA-LOADER: failed to retrieve device information on virgl

https://bugs.freedesktop.org/show_bug.cgi?id=107309 --- Comment #1 from Emil Velikov --- The message is harmless since Mesa falls back to use the DRM driver name. That said, a slightly better (I'm obviously biased) solution has been on the list for ~month [1]. Just double-checked and pushed it t

[Bug 107309] libGL error: MESA-LOADER: failed to retrieve device information on virgl

https://bugs.freedesktop.org/show_bug.cgi?id=107309 Emil Velikov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[PATCH] drm/msm: mark PM functions as __maybe_unused

The suspend/resume functions are not referenced when power management is disabled: drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1288:12: error: 'dpu_runtime_resume' defined but not used [-Werror=unused-function] drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1261:12: error: 'dpu_runtime_suspend' defined but

Re: [PATCH] fbdev: fix modedb docs in fb_find_mode

On Thursday, July 05, 2018 03:52:17 PM Daniel Vetter wrote: > Fix up the indenting that confused sphinx. To make sure we > don't have to make the examples unreadable with escaping just > put them in as block quotes, that seems the simplest solution. > > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-f

Re: [PATCH] video: goldfishfb: fix memory leak on driver remove

On Friday, July 06, 2018 03:04:22 PM Anton Vasilyev wrote: > goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does > not have deallocation of fb, which leads to memory leak on probe/remove. > > The patch adds deallocation into goldfish_fb_remove(). > > Found by Linux Driver V

Re: [PATCH] omapfb: rename omap2 module to omap2fb.ko

On Monday, July 09, 2018 12:02:16 AM Tony Lindgren wrote: > * Arnd Bergmann [180706 12:39]: > > In a kernel configuration with both CONFIG_FB_OMAP=m and CONFIG_FB_OMAP2=m, > > Kbuild fails to point out that we have two modules with the same name > > (omapfb.ko), > > but instead fails with a crypt

Re: [PATCH] fbdev/via: fix defined but not used warning

On Saturday, July 07, 2018 08:29:36 AM Randy Dunlap wrote: > From: Randy Dunlap > > Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled > by marking the unused function as __maybe_unused. > > ../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: > 'viafb_sup_odev_proc_show' d

Re: [PATCH] fbdev: fbmem: mark expected switch fall-through

On Monday, July 09, 2018 04:36:08 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsu

Re: [PATCH] omapfb: Mark expected switch fall-throughs

On Monday, July 09, 2018 05:04:36 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsu

Re: [PATCH] video: fbdev: mark expected switch fall-throughs

On Monday, July 09, 2018 05:41:45 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsu

Re: [PATCH v2] console: Replace #if 1 with a bool to ignore

On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote: > > From: Steven Rostedt (VMware) > > There's been discussion on the fb list about the addition of > WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when > the fb module is loaded with lockless_register_fb the console

Re: [PATCH v2] console: Replace #if 1 with a bool to ignore

On Tuesday, July 24, 2018 06:13:19 PM Bartlomiej Zolnierkiewicz wrote: > On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote: > > > > From: Steven Rostedt (VMware) > > > > There's been discussion on the fb list about the addition of > > WARN_CONSOLE_UNLOCKED() inside the fb code. The com

Re: [PATCH 1/2] drm/dp: add extended receiver capability field present bit

On Mon, Jul 23, 2018 at 02:27:34PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > This bit was added to DP Training Aux RD interval with DP 1.3. Via > descriptiion of the spec this field indicates the panels true > capabilities are described in DPCD address space 02200h through

Re: [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

On Mon, Jul 23, 2018 at 02:27:35PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > According to DP spec (2.9.3.1 of DP 1.4) if > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD > 02200h through 0220Fh shall contain the DPRX's true capability. These > value

  1   2   >