Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

On 23/05/17 12:50 PM, Lukas Wunner wrote: > On Tue, May 23, 2017 at 12:09:49PM +0900, Michel Dänzer wrote: >> On 22/05/17 11:04 PM, Lukas Wunner wrote: >>> On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote: On Thu, May 18 2017, Lukas Wunner wrote: >>> [snip] > Reported-by:

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

On Tue, May 23, 2017 at 12:09:49PM +0900, Michel Dänzer wrote: > On 22/05/17 11:04 PM, Lukas Wunner wrote: > > On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote: > >> On Thu, May 18 2017, Lukas Wunner wrote: > > [snip] > >>> Reported-by: Nicolai Stange > >>>

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

On 22/05/17 11:04 PM, Lukas Wunner wrote: > On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote: >> On Thu, May 18 2017, Lukas Wunner wrote: > [snip] >>> Reported-by: Nicolai Stange >>> Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with >>>

[Bug 100949] Power management problem on CIK/SI hybrid laptop

https://bugs.freedesktop.org/show_bug.cgi?id=100949 --- Comment #7 from Michel Dänzer --- I'm still unclear as to the symptoms you're seeing. E.g., are the *ERROR* messages always accompanied by a black laptop panel? And does this only happen on suspend/resume, or also under

Re: [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl

On 22/05/17 10:59 PM, Daniel Vetter wrote: > I failed to properly onion-wrap the unwind code: We acquire the vblank > reference before we start with the wait-wound locking dance, hence we > must make sure we retry before we drop the reference. Oops. > > v2: The vblank_put must be after the

Re: [PATCH v2 1/5] drm/stm: ltdc: Add bridge support

Hi Philippe, W dniu 2017-05-20 o 00:20, Philippe CORNU pisze: Add the bridge support, used by DSI host and HDMI/LVDS bridges. Signed-off-by: Philippe CORNU --- drivers/gpu/drm/stm/ltdc.c | 74 ++ drivers/gpu/drm/stm/ltdc.h

linux-next: manual merge of the drm-misc tree with the drm-intel tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/intel_display.c between commits: 1cecc830e6b6 ("drm/i915: Refactor CURBASE calculation") 024faac7d59b ("drm/i915: Support variable cursor height on ivb+") from the drm-intel tree and commit:

[PATCH 13/22] gpu: host1x: Do not leak BO's phys address to userspace

Do gathers coping before patching them, so the original gathers are left untouched. That's not as bad as leaking a kernel addresses, but still doesn't feel right. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 44 ++-- 1

Re: [PATCH v4 05/10] drm: arc: Use crtc->mode_valid() callback

Hi Jose, The only nitpicking note from my side is patch name. Probably full driver name as "arcpgu" might give a bit more context especially if later something else from ARC appears in "drm" folder. But IMHO that doesn't worth another respin. On Fri, 2017-05-19 at 01:52 +0100, Jose Abreu wrote:

[PATCH v3 5/5] drm: rcar-du: Map memory through the VSP device

From: Laurent Pinchart For planes handled by a VSP instance, map the framebuffer memory through the VSP to ensure proper IOMMU handling. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

[PATCH 15/22] gpu: host1x: Forbid RESTART opcode in the firewall

The RESTART opcode terminates the gather and restarts the CDMA fetching from a specified word << 2 relative to the CDMA start address. That shouldn't be allowed to be done by userspace. Signed-off-by: Dmitry Osipenko Reviewed-by: Erik Faye-Lund ---

[PATCH 16/22] gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall

Several channels could be made to write the same unit concurrently via the SETCLASS opcode, trusting userspace is a bad idea. It should be possible to drop the per-client channel reservation and add a per-unit locking by inserting MLOCK's to the command stream to re-allow the SETCLASS opcode, but

[PATCH 07/22] drm/tegra: Remove module ownership from the tegra_fb_ops

The framebuffers console fbcon_startup() increments the tegra_drm module 'use' refcount via try_module_get(), causing an interlock of the DRM subsys and the tegra_drm modules. In result, the tegra_drm module can't be unloaded using rmmod. Signed-off-by: Dmitry Osipenko ---

[PATCH 19/22] gpu: host1x: Remove unused host1x_cdma_stop() definition

There is no host1x_cdma_stop() in the code, let's remove its definition from the header file. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/cdma.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h index

Re: [PATCH v4 00/10] Introduce new mode validation callbacks

Hi Daniel, On 22-05-2017 08:56, Daniel Vetter wrote: > On Fri, May 19, 2017 at 01:52:09AM +0100, Jose Abreu wrote: >> This series is a follow up from the discussion at [1]. We start by >> introducing crtc->mode_valid(), encoder->mode_valid() and >> bridge->mode_valid() callbacks which will be

[PATCH 04/22] drm/tegra: Check for malformed offsets and sizes in the 'submit' IOCTL

If commands buffer claims a number of words that is higher than its BO can fit, a kernel OOPS will be fired on the out-of-bounds BO access. This was triggered by an opentegra Xorg driver that erroneously pushed too many commands to the pushbuf. The CMDA commands buffer address is 4 bytes aligned,

[PATCH 10/22] drm/tegra: Disable plane if it is invisible

On Tegra20 if plane has width or height equal to 0, it will be infinitely wide or tall. Let's disable the plane if it is invisible on atomic state committing to fix the issue. The Rockchip DRM driver does the same. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c

[PATCH 05/22] drm/tegra: Correct copying of waitchecks and disable them in the 'submit' IOCTL

The waitchecks along with multiple syncpoints per submit are not ready for use yet, let's forbid them for now. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/drm.c | 60 ++--- drivers/gpu/host1x/job.h| 7 --

[PATCH 22/22] Revert "iommu/tegra: gart: Do not register with bus"

The GART driver was disabled because it was picked by as an IOMMU provider for the DRM driver on Tegra20, which is not the purpose of the GART. Now DRM driver avoids to use IOMMU on Tegra20, so the GART driver can be re-enabled. Potentially there are interesting use cases of the GART for Tegra20,

Re: [PATCH] gpu: drm: gma500: remove two more dead variable

Hi Arnd, Quoting Arnd Bergmann : The dead code removal left two unused variables: drivers/gpu/drm/gma500/mdfld_tpo_vid.c: In function 'tpo_vid_get_config_mode': drivers/gpu/drm/gma500/mdfld_tpo_vid.c:34:31: error: unused variable 'ti' [-Werror=unused-variable] This

[PATCH v3 4/5] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP

From: Laurent Pinchart The display buffers must be mapped for DMA through the device that performs memory access. Expose an API to map and unmap memory through the VSP device to be used by the DU. As all the buffers allocated by the DU driver are

Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device

Hi Laurent, On 22/05/17 13:24, Laurent Pinchart wrote: > Hi Kieran, > > On Monday 22 May 2017 13:16:11 Kieran Bingham wrote: >> On 17/05/17 00:20, Laurent Pinchart wrote: >>> For planes handled by a VSP instance, map the framebuffer memory through >>> the VSP to ensure proper IOMMU handling. >>>

[PATCH 21/22] drm/tegra: Don't use IOMMU on Tegra20

There is no IOMMU on Tegra20, instead a GART would be picked as an IOMMU provider. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/drm.c | 5 - drivers/gpu/host1x/dev.c| 5 - 2 files changed, 8 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] drm/pl111: add ARM_AMBA dependency

On Mon, May 22, 2017 at 05:20:08PM +0200, Arnd Bergmann wrote: > The driver is written in a way to enable compile-testing without > CONFIG_ARM_AMBA, > but it just causes needless warnings: > > drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined > but not used

[PATCH v3 3/5] v4l: vsp1: Map the DL and video buffers through the proper bus master

From: Magnus Damm On Gen2 hardware the VSP1 is a bus master and accesses the display list and video buffers through DMA directly. On Gen3 hardware, however, memory accesses go through a separate IP core called FCP. The VSP1 driver unconditionally maps DMA buffers through

Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device

Hi Laurent, Thankyou for the patch. On 17/05/17 00:20, Laurent Pinchart wrote: > For planes handled by a VSP instance, map the framebuffer memory through > the VSP to ensure proper IOMMU handling. > > Signed-off-by: Laurent Pinchart Looks good except

[PATCH 09/22] drm/tegra: dc: Apply clipping to the plane

On Tegra20 an overlay plane should be clipped, otherwise its output is distorted once plane crosses display boundary. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c | 29 + 1 file changed, 21 insertions(+), 8 deletions(-) diff --git

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

On 05/22/2017 08:52 PM, Fabio Estevam wrote: > Hi Marek, Hi! > On Mon, May 22, 2017 at 11:20 AM, Marek Vasut wrote: > >> IMO it's OK. >> >> Reviewed-by: Marek Vasut > > Thanks for the feedback. > > Do you plan to send Dave a pull request so that this one can

[PATCH 17/22] gpu: host1x: Check waits in the firewall

Check waits in the firewall in a way it is done for relocations. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 36 ++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/host1x/job.c

Re: [PATCH v3 0/5] R-Car DU: Fix IOMMU operation when connected to VSP

Hi Mauro, I would like this series to go in the same pull-request to the DRM tree as the previous series you acked. Again, the series touches both V4L2, and DRM, to provide another fix up the Rcar-DU driver. I have reviewed and tested the whole series Would it be possible to get your Acked-by:

[PATCH v3 0/5] R-Car DU: Fix IOMMU operation when connected to VSP

Hello, This patch series fixes the rcar-du-drm driver to support VSP plane sources with an IOMMU. It is available for convenience at git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git vsp-du/iommu-fcp On R-Car Gen3 the DU has no direct memory access but sources planes through VSP

[PATCH 02/22] drm/tegra: Correct idr_alloc() minimum id

The client ID 0 is reserved by the host1x/cdma to mark the timeout timer work as already been scheduled and context ID is used as the clients one. This fixes spurious CDMA timeouts. Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace") Signed-off-by: Dmitry Osipenko

[PATCH 12/22] gpu: host1x: Correct host1x_job_pin() error handling

In case of relocations / waitchecks patching failure the jobs pins stay referenced till DRM file get closed, wasting memory. Add the missed unpinning. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 16 +++- 1 file changed, 7 insertions(+), 9

[PATCH 11/22] gpu: host1x: Initialize firewall class to the jobs one

The commands stream is prepended by the jobs class on the CDMA submission, so that explicitly setting a module class in the commands stream isn't necessary. The firewall initializes its class to 0 and the command stream that doesn't explicitly specify the class effectively bypasses the firewall.

Re: [PATCH] drm/stm: add COMPILE_TEST to Kconfig (fwd)

On 05/20/2017 07:32 PM, Masahiro Yamada wrote: > Hi Philippe, > > > 2017-05-19 21:17 GMT+09:00 Philippe CORNU : >> >> >> On 05/19/2017 09:49 AM, Julia Lawall wrote: >>> On line 466, the preceeding comment suggests that the second constant >>> should start with VS rather

[PATCH 08/22] drm/tegra: dc: Drop the reset asserts to workaround a bug

Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It causes a hang on Tegra20 if both display controllers are utilized (RGB panel and HDMI). The TRM suggests that each display controller has its own reset control, apparently it is not correct. Let's remove the interaction with

[PATCH] gpu: drm: nouveau: add null check before pointer dereference

Add null check before dereferencing pointer asyc Addresses-Coverity-ID: 1397932 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/nouveau/nv50_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c

[PATCH v3 1/5] v4l: rcar-fcp: Don't get/put module reference

From: Laurent Pinchart Direct callers of the FCP API hold a reference to the FCP module due to module linkage, there's no need to take another one manually. Take a reference to the device instead to ensure that it won't disappear behind the caller's

[PATCH 14/22] gpu: host1x: Forbid relocation address shifting in the firewall

Incorrectly shifted relocation address will cause a lower memory corruption and likely a hang on a write or a read of an arbitrary data in case of IOMMU absent. As of now there is no use for the address shifting (at least on Tegra20) and adding a proper shifting / sizes validation is much more

[PATCH 20/22] gpu: host1x: Refactor channel allocation code

From: Mikko Perttunen This is largely a rewrite of the Host1x channel allocation code, bringing several changes: - The previous code could deadlock due to an interaction between the 'reflock' mutex and CDMA timeout handling. This gets rid of the mutex. - Support for

Re: [PATCH v2 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device

Hi Laurent, Thankyou for the patch: On 17/05/17 00:20, Laurent Pinchart wrote: > The new rcar_fcp_get_device() function retrieves the struct device > related to the FCP device. This is useful to handle DMA mapping through > the right device. > > Signed-off-by: Laurent Pinchart

Re: [PATCH v2 4/5] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP

Hi Laurent, On 17/05/17 00:20, Laurent Pinchart wrote: > The display buffers must be mapped for DMA through the device that > performs memory access. Expose an API to map and unmap memory through > the VSP device to be used by the DU. > > As all the buffers allocated by the DU driver are

Re: [PATCH v2 1/5] v4l: rcar-fcp: Don't get/put module reference

Hi Laurent, Thanks for the patch: On 17/05/17 00:20, Laurent Pinchart wrote: > Direct callers of the FCP API hold a reference to the FCP module due to > module linkage, there's no need to take another one manually. Take a > reference to the device instead to ensure that it won't disappear behind

[PATCH 18/22] gpu: host1x: Remove unused 'struct host1x_cmdbuf'

The struct host1x_cmdbuf is unused, let's remove it. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/host1x/job.h b/drivers/gpu/host1x/job.h index 0debd93a1849..4bda51d503ec 100644 ---

Re: drm: Primary display is recognized as secondary display

On Mon, May 22, 2017 at 09:22:03AM +0100, Chris Wilson wrote: > On Sat, May 20, 2017 at 10:02:32PM +0900, Hisao Tanabe wrote: > > DELL 27-inch display is connected to ThinkPad 250 via DisplayPort cable, > > and DELL 27-inch display is used as primary display. > > > > After upgrade kernel from

[PATCH 00/22] Tegra DRM fixes

Hello, I have already sent some of the patches contained in this series and some of them got reviews. Later I added couple more patches and the dependencies started to form, so please ignore all the patches I sent before this series. The patches without r-b signatures require a review. Dmitry

[PATCH v3 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device

From: Laurent Pinchart The new rcar_fcp_get_device() function retrieves the struct device related to the FCP device. This is useful to handle DMA mapping through the right device. Signed-off-by: Laurent Pinchart

[PATCH 03/22] drm/tegra: Check whether page belongs to BO in tegra_bo_kmap()

This fixes an OOPS in case of out-of-bounds accessing of a kmap'ed cmdbuf (non-IOMMU allocation) while patching the relocations in do_relocs(). Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH v3 12/16] drm/stm: remove unneeded -Iinclude/drm compiler flag

Hi Daniel, 2017-05-22 16:37 GMT+09:00 Daniel Vetter : > On Thu, May 18, 2017 at 01:29:49PM +0900, Masahiro Yamada wrote: >> With the include directives under include/drm/ fixed, this flag is >> no longer needed. >> >> Signed-off-by: Masahiro Yamada

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

On 05/22/2017 03:55 PM, Fabio Estevam wrote: > Hi Marek, > > On Fri, May 5, 2017 at 3:01 PM, Fabio Estevam wrote: >> According to the eLCDIF initialization steps listed in the MX6SX >> Reference Manual the eLCDIF block reset is mandatory. >> >> Without performing the

Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device

On 22/05/17 14:23, Laurent Pinchart wrote: > Hello Geert and Kieran, > > On Monday 22 May 2017 15:00:27 Geert Uytterhoeven wrote: >> On Mon, May 22, 2017 at 2:52 PM, Kieran Bingham wrote: >>> My only distaste there is having to then add the [i-1] index to the >>> sg_tables. >>> >>> I have just

Re: [PATCH v2 3/5] v4l: vsp1: Map the DL and video buffers through the proper bus master

Hi Laurent, Thanks for the patch: On 17/05/17 00:20, Laurent Pinchart wrote: > From: Magnus Damm > > On Gen2 hardware the VSP1 is a bus master and accesses the display list > and video buffers through DMA directly. On Gen3 hardware, however, > memory accesses go through

Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device

Hi Laurent, Thankyou for the patch. On 17/05/17 00:20, Laurent Pinchart wrote: > For planes handled by a VSP instance, map the framebuffer memory through > the VSP to ensure proper IOMMU handling. > > Signed-off-by: Laurent Pinchart Looks good except

[PATCH] drm/stm: ltdc: fix duplicated arguments

Fix COMPILE_TEST build issue detected with the rule: "duplicated argument to & or |" Signed-off-by: Philippe CORNU --- drivers/gpu/drm/stm/ltdc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c

[PATCH 01/22] drm/tegra: Fix lockup on a use of staging API

Commit bdd2f9cd ("Don't leak kernel pointer to userspace") added a mutex around staging IOCTL's, some of those mutexes are taken twice. Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace") Signed-off-by: Dmitry Osipenko Reviewed-by: Mikko Perttunen

Re: drm: Primary display is recognized as secondary display

On Mon, May 22, 2017 at 09:22:03AM +0100, Chris Wilson wrote: > On Sat, May 20, 2017 at 10:02:32PM +0900, Hisao Tanabe wrote: > > DELL 27-inch display is connected to ThinkPad 250 via DisplayPort cable, > > and DELL 27-inch display is used as primary display. > > > > After upgrade kernel from

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

Hi, Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec wrote: > > Hi, > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard

[PATCH 06/22] drm/tegra: Check syncpoint ID in the 'submit' IOCTL

In case of invalid syncpoint ID, the host1x_syncpt_get() returns NULL and none of its users perform a check of the returned pointer later. Let's bail out until it's too late. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/drm.c | 9 + 1 file changed, 9

Re: [PATCH 19/22] gpu: host1x: Remove unused host1x_cdma_stop() definition

On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote: > There is no host1x_cdma_stop() in the code, let's remove its definition > from the header file. > > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/host1x/cdma.h | 1 - > 1 file changed, 1

Re: [PATCH 18/22] gpu: host1x: Remove unused 'struct host1x_cmdbuf'

On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote: > The struct host1x_cmdbuf is unused, let's remove it. > > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/host1x/job.h | 7 --- > 1 file changed, 7 deletions(-) > > diff --git

Re: [PATCH 16/22] gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall

On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote: > Several channels could be made to write the same unit concurrently via the > SETCLASS opcode, trusting userspace is a bad idea. It should be possible to > drop the per-client channel reservation and add a per-unit locking

Re: [PATCH 14/22] gpu: host1x: Forbid relocation address shifting in the firewall

On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote: > Incorrectly shifted relocation address will cause a lower memory corruption > and likely a hang on a write or a read of an arbitrary data in case of IOMMU > absent. As of now there is no use for the address shifting (at

Re: [PATCH v3 19/21] drm/sun4i: Add compatible for the A10s pipeline

On Wed, May 17, 2017 at 09:40:48AM +0200, Maxime Ripard wrote: > The A10s has a slightly different display pipeline than the A13, with an > HDMI controller. > > Add a compatible for it. > > Signed-off-by: Maxime Ripard > --- >

Re: [PATCH 12/22] gpu: host1x: Correct host1x_job_pin() error handling

On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote: > In case of relocations / waitchecks patching failure the jobs pins stay > referenced till DRM file get closed, wasting memory. Add the missed > unpinning. > > Signed-off-by: Dmitry Osipenko > --- >

Re: [PATCH 03/22] drm/tegra: Check whether page belongs to BO in tegra_bo_kmap()

On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote: > This fixes an OOPS in case of out-of-bounds accessing of a kmap'ed cmdbuf > (non-IOMMU allocation) while patching the relocations in do_relocs(). > > Signed-off-by: Dmitry Osipenko > --- >

Re: [PATCH] gpu: drm: gma500: remove two more dead variable

On Mon, May 22, 2017 at 10:30 PM, Arnd Bergmann wrote: > The dead code removal left two unused variables: > > drivers/gpu/drm/gma500/mdfld_tpo_vid.c: In function 'tpo_vid_get_config_mode': > drivers/gpu/drm/gma500/mdfld_tpo_vid.c:34:31: error: unused variable 'ti' >

Re: [PATCH v2] gpu: drm: gma500: remove dead code

On Fri, May 19, 2017 at 2:28 PM, Patrik Jakobsson wrote: > On Fri, May 19, 2017 at 11:19 AM, Gustavo A. R. Silva > wrote: >> Local variable use_gct is assigned to a constant value and it is never >> updated again. Remove this variable and

Re: [PATCH] gpu: drm: nouveau: add null check before pointer dereference

On 05/23/2017 05:12 AM, Gustavo A. R. Silva wrote: Add null check before dereferencing pointer asyc I've taken the patch into my tree, thanks! Ben. Addresses-Coverity-ID: 1397932 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/nouveau/nv50_display.c | 3

Re: [PATCH -next] drm/pl111: Fix return value check in pl111_amba_probe()

Wei Yongjun writes: > From: Wei Yongjun > > In case of error, the function devm_ioremap_resource() returns ERR_PTR() > and never returns NULL. The NULL test in the return value check should > be replaced with IS_ERR(). > > Fixes: bed41005e617

Re: [PATCH] drm/pl111: add ARM_AMBA dependency

Arnd Bergmann writes: > On Mon, May 22, 2017 at 6:23 PM, Eric Anholt wrote: >> Arnd Bergmann writes: >> >>> The driver is written in a way to enable compile-testing without >>> CONFIG_ARM_AMBA, >>> but it just causes needless warnings: >>> >>>

[Bug 100437] IO_PAGE_FAULT is spammed in dmesg

https://bugs.freedesktop.org/show_bug.cgi?id=100437 --- Comment #9 from Greg Turner --- Just another datapoint on this... I have this disease with a (non-reference) Asus RX480 in an Asus Sabertooth Gen3 R2.0 (or something like that, I can never remember exactly what it's

Re: [PATCH] drm/pl111: add ARM_AMBA dependency

On Mon, May 22, 2017 at 6:23 PM, Eric Anholt wrote: > Arnd Bergmann writes: > >> The driver is written in a way to enable compile-testing without >> CONFIG_ARM_AMBA, >> but it just causes needless warnings: >> >> drivers/gpu/drm/pl111/pl111_drv.c:149:26: error:

Re: [PATCH] drm/pl111: add ARM_AMBA dependency

On Mon, May 22, 2017 at 6:32 PM, Krzysztof Kozlowski wrote: > On Mon, May 22, 2017 at 05:20:08PM +0200, Arnd Bergmann wrote: >> The driver is written in a way to enable compile-testing without >> CONFIG_ARM_AMBA, >> but it just causes needless warnings: >> >>

[Bug 194761] amdgpu driver breaks on Oland (SI)

https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #15 from Jean Delvare (jdelv...@suse.de) --- And it's not just me, see: https://bugzilla.opensuse.org/show_bug.cgi?id=1039806 -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH RESEND] drm: mxsfb_crtc: Reset the eLCDIF controller

From: Fabio Estevam According to the eLCDIF initialization steps listed in the MX6SX Reference Manual the eLCDIF block reset is mandatory. Without performing the eLCDIF reset the display shows garbage content when the kernel boots. In earlier tests this issue has not

Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

Laurent Pinchart writes: > Hi Archit, > > On Friday 19 May 2017 14:24:36 Archit Taneja wrote: >> On 05/18/2017 08:25 PM, Laurent Pinchart wrote: >> > On Thursday 18 May 2017 13:56:19 Archit Taneja wrote: >> >> On 05/17/2017 12:16 AM, Eric Anholt wrote: >> > >>

Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

Laurent Pinchart writes: > Hi Eric, > > On Tuesday 16 May 2017 11:46:36 Eric Anholt wrote: > > [snip] > >> In terms of physical connections: >> >>[15-pin "DSI" connector on 2835] >> >> | I2C | DSI >>/ \SPI | >> [TS]

[PATCH] gpu: drm: gma500: remove two more dead variable

The dead code removal left two unused variables: drivers/gpu/drm/gma500/mdfld_tpo_vid.c: In function 'tpo_vid_get_config_mode': drivers/gpu/drm/gma500/mdfld_tpo_vid.c:34:31: error: unused variable 'ti' [-Werror=unused-variable] This removes them as well. Fixes: 94d7fb4982d2 ("gpu: drm: gma500:

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

On Mon, May 22, 2017 at 04:04:07PM +0200, Lukas Wunner wrote: > On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote: > > On Thu, May 18 2017, Lukas Wunner wrote: > [snip] > > > Reported-by: Nicolai Stange > > > Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register

Re: [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name

On Tue, May 16, 2017 at 12:10:42PM +0100, Chris Wilson wrote: > Constructing the name takes the majority of the time for allocating a > sync_file to wrap a fence, and the name is very rarely used (only via > the sync_file status user interface). To reduce the impact on the common > path (that of

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

On Thu, May 18, 2017 at 09:33:44PM +0200, Lukas Wunner wrote: > Nicolai Stange reports the following oops which is caused by > dereferencing rdev->pdev before it's subsequently set by > radeon_device_init(). Fix it. > > BUG: unable to handle kernel NULL pointer dereference at 07cb

[Bug 195743] Screen flicker and instability on hdmi monitors with AMDGPU, EDID problems

https://bugzilla.kernel.org/show_bug.cgi?id=195743 keziolio...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl

2017-05-22 16:59 GMT+03:00 Daniel Vetter : > I failed to properly onion-wrap the unwind code: We acquire the vblank > reference before we start with the wait-wound locking dance, hence we > must make sure we retry before we drop the reference. Oops. > > v2: The vblank_put

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

Hi Marek, On Mon, May 22, 2017 at 11:20 AM, Marek Vasut wrote: > IMO it's OK. > > Reviewed-by: Marek Vasut Thanks for the feedback. Do you plan to send Dave a pull request so that this one can reach 4.12-rc? Thanks

[Bug 101145] Wine game needs GLSL override for fullscreen

https://bugs.freedesktop.org/show_bug.cgi?id=101145 --- Comment #2 from wyrex --- Created attachment 131439 --> https://bugs.freedesktop.org/attachment.cgi?id=131439=edit log with override -- You are receiving this mail because: You are the assignee for the

[Bug 101145] Wine game needs GLSL override for fullscreen

https://bugs.freedesktop.org/show_bug.cgi?id=101145 --- Comment #1 from wyrex --- Created attachment 131438 --> https://bugs.freedesktop.org/attachment.cgi?id=131438=edit without override -- You are receiving this mail because: You are the assignee for the

[Bug 101145] Wine game needs GLSL override for fullscreen

https://bugs.freedesktop.org/show_bug.cgi?id=101145 Bug ID: 101145 Summary: Wine game needs GLSL override for fullscreen Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH] drm/pl111: add ARM_AMBA dependency

Arnd Bergmann writes: > The driver is written in a way to enable compile-testing without > CONFIG_ARM_AMBA, > but it just causes needless warnings: > > drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined > but not used [-Werror=unused-variable] >

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #49 from Rodhos --- My monitor is Samsung SyncMaster 2032BW. It happens after Ubuntu changing the default drivers. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v4 2/2] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

On Fri, May 19, 2017 at 04:50:17PM -0400, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic API, but realizing that userspace is likely to take >

Re: [PATCH libdrm] Android's major/minor/makedev live in

On 20 May 2017 at 19:24, enh wrote: > Bug: https://github.com/android-ndk/ndk/issues/398 > --- > Android.common.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Android.common.mk b/Android.common.mk > index 35c0f02c..b45ca10f 100644 > --- a/Android.common.mk > +++

[Bug 100949] Power management problem on CIK/SI hybrid laptop

https://bugs.freedesktop.org/show_bug.cgi?id=100949 --- Comment #6 from Luya Tshimbalanga --- Last commit that worked prior to the breakage was on 20170410. I just updated to the recent 20170511 which seems partially resolving the issue but the error message below still

Re: [PATCH v4 00/10] Introduce new mode validation callbacks

On Mon, May 22, 2017 at 09:56:00AM +0200, Daniel Vetter wrote: > On Fri, May 19, 2017 at 01:52:09AM +0100, Jose Abreu wrote: > > This series is a follow up from the discussion at [1]. We start by > > introducing crtc->mode_valid(), encoder->mode_valid() and > > bridge->mode_valid() callbacks which

[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon

https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #6 from Trevor Davenport --- >From phoronix's data this appears to not happen on Tahiti chips. The 270x and 370 are always slower on amdgpu compared to radeon. See

[PATCH] drm/pl111: add ARM_AMBA dependency

The driver is written in a way to enable compile-testing without CONFIG_ARM_AMBA, but it just causes needless warnings: drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined but not used [-Werror=unused-variable] drivers/gpu/drm/pl111/pl111_drv.c:81:12: error:

[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon

https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #5 from Maxim Sheviakov --- Created attachment 131436 --> https://bugs.freedesktop.org/attachment.cgi?id=131436=edit dmesg | egrep 'drm|radeon' -- You are receiving this mail because: You are the assignee

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #48 from Jonas --- I have an Asus MG278Q, which is the TN model, and the issue is not the same as explained in the thread you have linked. Under Archlinux what happens above 60Hz is a crazy flickering of

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #47 from Eike --- This problem also occurs on certain graphics & monitor driver combinations on Windows and is according to the linked thread a firmware problem of the Asus MG279Q. This almost only happens with GCN2

[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon

https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #4 from Maxim Sheviakov --- Created attachment 131435 --> https://bugs.freedesktop.org/attachment.cgi?id=131435=edit dmesg | egrep 'drm|amdgpu' -- You are receiving this mail because: You are the assignee

[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon

https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #3 from Maxim Sheviakov --- Same here. Using Arch x86_64 with linux-ck 4.11.2 and mesa 17.1.0. AMDGPU's performance is about 60~70% of radeon's on MSI R7 370 Armor 2X. -- You are receiving this mail because:

  1   2   >