[Bug 101401] [REGRESSION][BISECTED] GDM fails to start after 8ec4975cd83365c791a1

https://bugs.freedesktop.org/show_bug.cgi?id=101401 Aaron Watry changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)

https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #12 from Michel Dänzer --- Mesa doesn't support GL_EXT_gpu_shader4, so it looks like there's a bug in UE4(Editor). Not sure the GPU hang is directly related to that though. -- You are receiving this mail

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

On 14.06.2017 09:50, Mikko Perttunen wrote: > On 14.06.2017 02:15, 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

[PATCH v2 2/6] drm/i915: update cursors asynchronously through atomic

From: Gustavo Padovan Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what intel_legacy_cursor_update() did but through atomic. v3: - set correct vma to new state for cleanup

[PATCH v2 3/6] drm/i915: remove intel_cursor_plane_funcs

From: Gustavo Padovan After converting legacy cursor updates to atomic async commits intel_cursor_plane_funcs just duplicates intel_plane_funcs now. Cc: Daniel Vetter Signed-off-by: Gustavo Padovan ---

[PATCH v2 0/6] drm: add asynchrounous plane update

From: Gustavo Padovan Hi, Another iteration on this patchset. Added some a-b and r-b tags to it and fixed issues in patch 6 reported by Eric. That patch still needs testing but the rest is tested and working, looking to be already in a good shape. More info in the

[PATCH v2 5/6] drm/msm: remove mdp5_cursor_plane_funcs

From: Gustavo Padovan After converting legacy cursor updates to atomic async commits mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now. Cc: Rob Clark Cc: Archit Taneja Signed-off-by: Gustavo Padovan

[PATCH v2 6/6] drm/vc4: update cursors asynchronously through atomic

From: Gustavo Padovan Add support for async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what vc4_update_plane() did but through atomic. v4: add drm_atomic_helper_async() commit (Eric Anholt) v3: move size

[PATCH v2 4/6] drm/msm: update cursors asynchronously through atomic

From: Gustavo Padovan Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what mdp5_update_cursor_plane_legacy() did but through atomic. v4: add missing atomic async commit call to

[PATCH v2 1/6] drm/atomic: initial support for asynchronous plane update

From: Gustavo Padovan In some cases, like cursor updates, it is interesting to update the plane in an asynchronous fashion to avoid big delays. The current queued update could be still waiting for a fence to signal and thus block any subsequent update until its

Re: [PATCH v3 01/14] drm: add HDMI 2.0 VIC support for AVI info-frames

Hello Thierry, Thanks for the comments. In fact, that was the plan earlier, but the problem is, this function is being called from several drivers, and not all of them have the drm_connector readily available with their caller function. For few drivers, I might have to go up two to three

Re: [PATCH v5 6/6] drm/amdgpu: resize VRAM BAR for CPU access v3

On Fri, Jun 09, 2017 at 10:59:47AM +0200, Christian König wrote: > From: Christian König > > Try to resize BAR0 to let CPU access all of VRAM. > > v2: rebased, style cleanups, disable mem decode before resize, > handle gmc_v9 as well, round size up to power of two.

Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

14.06.2017 16:42, Sean Paul wrote: [Discussion of vboxvideo driver kernel integration and clean-up.] > Once the code is upstream, it's going to be difficult to motivate developers > to > keep the driver close to your downstream version. If I'm working on feature X > which touches your driver, I'm

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

On 14.06.2017 12:06, Dmitry Osipenko wrote: On 14.06.2017 09:50, Mikko Perttunen wrote: On 14.06.2017 02:15, 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.

[PATCH] drm: Fix boot panic when register_chrdev fails

This is a bug found by the 0day kernel test robot. When drm is compiled into the kernel, and register_chrdev fails (due, in this, case to overfilling the chardev dynamic major numbers), a kernel panic occurs on boot: BUG: unable to handle kernel NULL pointer dereference at

[PATCH v3 09/20] 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.

[PATCH v3 05/20] 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 Reviewed-by: Mikko Perttunen ---

[PATCH v3 04/20] 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 Reviewed-by: Mikko Perttunen --- drivers/gpu/drm/tegra/drm.c | 60 ++---

[PATCH v3 14/20] 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 v3 02/20] 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

Re: [PATCH 1/3] drm/omap: work-around for omap3 display enable

Hi, On Tue, Jun 13, 2017 at 12:02:08PM +0300, Tomi Valkeinen wrote: > Seems that on omap3 enabling a crtc without any planes causes a sync > lost flood. This only happens on the first enable, and after that it > works. This looks like an HW issue. > > It's unclear why this is happening or how to

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

On 14.06.2017 14:47, Mikko Perttunen wrote: > > > On 14.06.2017 12:06, Dmitry Osipenko wrote: >> On 14.06.2017 09:50, Mikko Perttunen wrote: >>> On 14.06.2017 02:15, Dmitry Osipenko wrote: Incorrectly shifted relocation address will cause a lower memory corruption and likely a hang on

[PATCH v3 08/20] drm/tegra: dc: 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 Reviewed-by: Erik Faye-Lund

[PATCH v3 06/20] drm/tegra: dc: Avoid reset asserts on Tegra20

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. Fixes: 33a8eb8d40ee ("drm/tegra:

Re: [PATCH 0/3] drm/omap: misc fixes

* Tomi Valkeinen [170613 02:06]: > Hi, > > Here's three fixes for omapdrm: > > - fix synclost flood on omap3 > - fix analog tv-out videomode check > - fix DSI PLL setup > > Tony, Aaro, Nikolaus, can you see if these fix the issues you're seeing? Seems to get rid of the

Re: [PATCH 0/3] drm/omap: misc fixes

Hi Tomi, > Am 13.06.2017 um 11:02 schrieb Tomi Valkeinen : > > Hi, > > Here's three fixes for omapdrm: > > - fix synclost flood on omap3 > - fix analog tv-out videomode check > - fix DSI PLL setup > > Tony, Aaro, Nikolaus, can you see if these fix the issues you're

[PATCH v3 20/20] gpu: host1x: At first try a non-blocking allocation for the gather copy

The blocking gather copy allocation is a major performance downside of the Host1x firewall, it may take hundreds milliseconds which is unacceptable for the real-time graphics operations. Let's try a non-blocking allocation first as a least invasive solution, it makes opentegra (Xorg driver)

[PATCH v3 01/20] 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: [Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

K Enviado desde mi iPhone ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)

https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #11 from Luke --- Hi Julien, Thanks for reproducing the problem! If the issue is related to GL_EXT_gpu_shader4, is it more likely the card not supporting it properly or a bug in the mesa driver?

Re: [PATCH libdrm v8] amdgpu: move asic id table to a separate file

On 14/06/17 08:34 PM, Emil Velikov wrote: > On 13 June 2017 at 10:45, Michel Dänzer wrote: >> From: Xiaojie Yuan >> >> v2: fix an off by one error and leading white spaces >> v3: use thread safe strtok_r(); initialize len before calling getline(); >>

Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

On 1 June 2017 at 11:06, Dave Airlie wrote: > From: Dave Airlie > > This creates a new command submission chunk for amdgpu > to add in and out sync objects around the submission. > > Sync objects are managed via the drm syncobj ioctls. > > The command

Re: [PATCH v2 22/22] gpu: host1x: At first try a non-blocking allocation for the gather copy

On 14.06.2017 10:56, Erik Faye-Lund wrote: > On Wed, Jun 14, 2017 at 1:16 AM, Dmitry Osipenko wrote: >> The blocking gather copy allocation is a major performance downside of the >> Host1x firewall, it may take hundreds milliseconds which is unacceptable >> for the real-time

[PATCH v3 13/20] 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

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

On 14.06.2017 02:15, 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 least on Tegra20) and adding a

Re: [PATCH] drm/msm: Separate locking of buffer resources from struct_mutex

Hi Rob, Yes, I’d completely missed the shrinker path in this cleanup. But, yeah, I see how get_pages (which is called with msm_obj->lock held) -> drm_gem_get_pages could trigger shrinker_scan which calls msm_gem_purge. It makes sense to prevent any get_pages/vmap on objects that’ve been marked

Re: [PATCH v2 09/22] drm/tegra: Don't use IOMMU on Tegra20

On 14.06.2017 13:22, Dmitry Osipenko wrote: > On 14.06.2017 10:39, Erik Faye-Lund wrote: >> On Wed, Jun 14, 2017 at 1:15 AM, Dmitry Osipenko wrote: >>> There is no IOMMU on Tegra20, instead a GART would be picked as an IOMMU >>> provider. >>> >>> Signed-off-by: Dmitry Osipenko

[PATCH] dt-bindings: display: sunxi: Improve endpoint ID scheme readability

The explanation for the endpoint ID numbering scheme is convoluted and hard to understand. This patch aims to improve the readability of it by combining the existing two paragraphs, while also providing a diagram example, and how endpoints should be numbered based on that example. Signed-off-by:

[PATCH v3] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states: "As in the general case the DDC bus is accessible by the kernel at the I2C level, drivers must make all reasonable efforts to expose it as an I2C adapter and use drm_get_edid() instead of abusing this function." Exposing

Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

Hello Sean, 13.06.2017 20:03, Sean Paul wrote: [Discussion of vboxvideo driver clean-up.] > First, thank you for your submission. Thank you for your feedback. [Discussion of the OS-independent code in the driver submission.] > I took a quick skim through your driver, and there doesn't seem to

[PATCH v3 00/20] Tegra DRM fixes

I've dropped the two "GART restoring" patches from the series, postponing them till a full solution of GART utilization would be ready. The "Forbid relocation address shifting in the firewall" patch has been reverted to v1, Mikko and me agreed on that it is a reasonable variant. All the patches

[PATCH v3 12/20] 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 absence. As of now, there is no known use for the address shifting and adding a proper shifts / sizes validation is a much more work. Let's

[PATCH v3 07/20] 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 Reviewed-by: Erik Faye-Lund --- drivers/gpu/drm/tegra/dc.c | 29 + 1 file

Re: [PATCH 21/44] powerpc: implement ->mapping_error

Christoph Hellwig writes: > DMA_ERROR_CODE is going to go away, so don't rely on it. Instead > define a ->mapping_error method for all IOMMU based dma operation > instances. The direct ops don't ever return an error and don't > need a ->mapping_error method. > > Signed-off-by:

Re: [PATCH RESEND v11 0/3] Enhancement to intel_dp_aux_backlight driver

Friendly ping. Is this patch set good to go now? On Mon, Jun 5, 2017 at 2:56 PM, Puthikorn Voravootivat wrote: > This patch set contain 3 patches which are already reviewed by DK. > Another 6 patches in previous version was already merged in v7 and v9. > - First patch sets

[PATCH v3 15/20] gpu: host1x: Correct swapped arguments in the is_addr_reg() definition

Arguments of the .is_addr_reg() are swapped in the definition of the function, that is quite confusing. Signed-off-by: Dmitry Osipenko Reviewed-by: Erik Faye-Lund Reviewed-by: Mikko Perttunen --- include/linux/host1x.h | 2 +- 1

[PATCH v3 03/20] 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 CDMA commands buffer address is 4 bytes aligned,

Re: [PATCH v2 09/22] drm/tegra: Don't use IOMMU on Tegra20

On 14.06.2017 10:39, Erik Faye-Lund wrote: > On Wed, Jun 14, 2017 at 1:15 AM, Dmitry Osipenko wrote: >> There is no IOMMU on Tegra20, instead a GART would be picked as an IOMMU >> provider. >> >> Signed-off-by: Dmitry Osipenko >> Acked-by: Joerg Roedel

[PATCH v3 19/20] 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: Resizeable PCI BAR support V5

On Fri, Jun 09, 2017 at 10:59:41AM +0200, Christian König wrote: > Hi everyone, > > This is the fith incarnation of this set of patches. It enables device > drivers to resize and most likely also relocate the PCI BAR of devices > they manage to allow the CPU to access all of the device local

[PATCH] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states: "As in the general case the DDC bus is accessible by the kernel at the I2C level, drivers must make all reasonable efforts to expose it as an I2C adapter and use drm_get_edid() instead of abusing this function." Exposing

Re: [PATCH v5 3/6] PCI: add functionality for resizing resources v6

On Fri, Jun 09, 2017 at 10:59:44AM +0200, Christian König wrote: > From: Christian König > > This allows device drivers to request resizing their BARs. > > The function only tries to reprogram the windows of the bridge directly above > the requesting device and only

[PATCH v3 16/20] 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 Reviewed-by: Mikko Perttunen Reviewed-by: Erik Faye-Lund --- drivers/gpu/host1x/job.c | 36 ++-- 1 file

[PATCH 1/1] drm/mgag200: Fix to always set HiPri for G200e4 V2

From: Mathieu Larouche - Changed the HiPri value for G200e4 to always be 0. - Added Bandwith limitation to block resolution above 1920x1200x60Hz Signed-off-by: Mathieu Larouche --- drivers/gpu/drm/mgag200/mgag200_mode.c | 9

Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

Hello Hans, 14.06.2017 15:30, Hans de Goede wrote: [Discussion of vboxvideo and vboxguest driver clean-up.] > As I already mentioned in previous mails on this, for the vboxguest driver > my plan is to simply do a fork and remove anything related to the > portability. It currently weighs in at

[PATCH v3 11/20] gpu: host1x: Do not leak BO's phys address to userspace

Perform gathers coping before patching them, so that original gathers are left untouched. That's not as bad as leaking kernel addresses, but still doesn't feel right. Signed-off-by: Dmitry Osipenko Reviewed-by: Mikko Perttunen ---

[PATCH v3 10/20] 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 Reviewed-by: Erik Faye-Lund Reviewed-by: Mikko Perttunen

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

On 06/14/2017 05:49 PM, Dmitry Osipenko wrote: On 14.06.2017 14:47, Mikko Perttunen wrote: On 14.06.2017 12:06, Dmitry Osipenko wrote: On 14.06.2017 09:50, Mikko Perttunen wrote: On 14.06.2017 02:15, Dmitry Osipenko wrote: Incorrectly shifted relocation address will cause a lower memory

Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

13.06.2017 17:41, Greg Kroah-Hartman wrote: [...] > And why is the closed vbox-devel list still on the cc: here, the bounces > from it are getting annoying. [...] Not sure why you are still getting them, but we added you to the white-list as well. I would prefer the list to stay on as the

[PATCH v3 17/20] gpu: host1x: Remove unused 'struct host1x_cmdbuf'

The struct host1x_cmdbuf is unused, let's remove it. Signed-off-by: Dmitry Osipenko Reviewed-by: Erik Faye-Lund Reviewed-by: Mikko Perttunen --- drivers/gpu/host1x/job.h | 7 --- 1 file changed, 7 deletions(-) diff --git

[BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

Hi, When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there is no display. Bisected to: a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit commit a09d2bc1503508c17ef3a71c6b1905e3660f3029 Author: Peter Ujfalusi Date: Tue May 3 22:08:01 2016

[PATCH v3 18/20] 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 Reviewed-by: Erik Faye-Lund Reviewed-by: Mikko Perttunen --- drivers/gpu/host1x/cdma.h | 1 - 1 file

Re: [PATCH 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

On Fri, Jun 09, 2017 at 01:59:12PM +0900, Hoegeun Kwon wrote: > The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using > MIPI-DSI interfaces. > > Signed-off-by: Hoegeun Kwon > --- > .../bindings/display/panel/samsung,s6e63j0x03.txt | 24 >

Re: [PATCH v3 1/3] drm/rockchip: dw_hdmi: add RK3399 HDMI support

On Fri, Jun 09, 2017 at 03:10:36PM +0800, Mark Yao wrote: > RK3399 and RK3288 shared the same HDMI IP controller, only some light > difference with GRF configure. > > Signed-off-by: Yakir Yang > Signed-off-by: Mark Yao > --- > Changes in v3: >

Re: [Intel-gfx] [PATCH][drm-next] drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static

On 13/06/2017 14:47, Colin King wrote: From: Colin Ian King The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global scope, so make it static. Cleans up sparse warning: "symbol 'cnl_ddi_dp_set_dpll_hw_state' was not declared. Should it be static?"

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

https://bugs.freedesktop.org/show_bug.cgi?id=96868 Psi changed: What|Removed |Added CC||w...@psitrax.de --- Comment #28

Re: [PATCH 1/1] drm/mgag200: Fix to always set HiPri for G200e4

On Tue, Jun 13, 2017 at 01:50:38PM -0400, mathieu.larou...@matrox.com wrote: > From: Mathieu Larouche > > - Changed the HiPri value for G200e4 to always be 0. > - Added Bandwith limitation to block resolution above 1920x1200x60Hz Hi Mathieu, There's no

Re: [PATCH v3 2/3] drm/rockchip: dw_hdmi: introduce the VPLL clock setting

On Fri, Jun 09, 2017 at 03:10:41PM +0800, Mark Yao wrote: > For RK3399 HDMI, there is an external clock need for HDMI PHY, > and it should keep the same clock rate with VOP DCLK. > > VPLL have supported the clock for HDMI PHY, but there is no > clock divider bewteen VPLL and HDMI PHY. So we need

Re: [PATCH v2 4/4] drm/panel: simple: add support for AUO P320HVN03

On Thu, Jun 08, 2017 at 08:07:58PM +0200, Lucas Stach wrote: > This adds support for the AU Optronics Corporation 31.5" > FHD (1920x1080) LVDS TFT LCD panel, which can be supported > by the simple panel driver > > Signed-off-by: Lucas Stach > --- > v2: mention

Re: [PATCH v2 3/4] drm/panel: simple: add support for NLT NL192108AC18-02D

On Thu, Jun 08, 2017 at 08:07:57PM +0200, Lucas Stach wrote: > This adds support for the NLT Technologies NL192108AC18-02D > 15.6" LVDS FullHD TFT LCD panel, which can be supported > by the simple panel driver. > > Timings are taken from the preliminary datasheet, as a final > one is not yet

Re: [PATCH 2/2] drm/radeon: Fix overflow of watermark calcs at > 4k resolutions.

On Tue, Jun 13, 2017 at 1:17 AM, Mario Kleiner wrote: > Commit e6b9a6c84b93 > ("drm/radeon: Make display watermark calculations more accurate") > made watermark calculations more accurate, but not for > 4k > resolutions on 32-Bit architectures, as it introduced an

Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

Hi all, On 14-06-17 11:34, Michael Thayer wrote: Hello Sean, 13.06.2017 20:03, Sean Paul wrote: [Discussion of vboxvideo driver clean-up.] First, thank you for your submission. Thank you for your feedback. [Discussion of the OS-independent code in the driver submission.] I took a quick

Re: [PATCH 1/3] mdacon: align code in mda_detect properly

On Friday, May 12, 2017 10:08:02 AM Jiri Slaby wrote: > This is just a whitespace cleanup. The code was a mess having multiple > commands on one line like: > scr_writew(0xAA55, p); if (scr_readw(p) == 0xAA55) count++; > > Indent that properly and make it nicer for reading. > > Signed-off-by:

Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

On Wed, Jun 14, 2017 at 11:34:10AM +0200, Michael Thayer wrote: > Hello Sean, > > 13.06.2017 20:03, Sean Paul wrote: > [Discussion of vboxvideo driver clean-up.] > > > First, thank you for your submission. > > Thank you for your feedback. > > [Discussion of the OS-independent code in the

Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

Hi, On 14-06-17 15:40, Michael Thayer wrote: Hello Hans, 14.06.2017 15:30, Hans de Goede wrote: [Discussion of vboxvideo and vboxguest driver clean-up.] As I already mentioned in previous mails on this, for the vboxguest driver my plan is to simply do a fork and remove anything related to the

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

https://bugs.freedesktop.org/show_bug.cgi?id=96868 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH 2/3] mdacon: make mda_vram_base u16 *

On Friday, May 12, 2017 10:08:03 AM Jiri Slaby wrote: > Given every user of mda_vram_base expects a pointer, let > mda_vram_base be a pointer to u16. > > The offset calculation in mda_detect had to be adjusted by / 2 (due to > different pointer arithmetic now). > > We introduce a cast to a value

Re: [PATCH 3/3] mdacon: replace MDA_ADDR macro by inline function

On Friday, May 12, 2017 10:08:04 AM Jiri Slaby wrote: > MDA_ADDR is one of those macros which could be an inline function. So > convert MDA_ADDR to mda_addr. > > Note that we take x and y as unsigned now. But they are absolute > coordinates, so this is no problem. > > Signed-off-by: Jiri Slaby

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Wait for pending modesets to complete before trying link training, v2.

On Wed, Jun 14, 2017 at 11:08:42AM +0200, Maarten Lankhorst wrote: > The nonblocking modeset tests were failing on systems with a DP output, > because lijnk training could occur during the modeset. > > With normal modesets we're protected by the connection_mutex lock, > but nonblocking modesets

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote: > Moving the wait to a helper allows callers outside of the core to > wait for pending updates to complete. > > This can be used to prevent races against nonblocking modesets. > Only the hw_done call in swap_state is moved to a

Re: [PATCH v2] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

Hello Hoegeun, my last question (does this regress the case "node required, but absent") still stands. Hoegeun Kwon wrote: > Remove the error handling of bridge_node because the bridge_node is > required optionally. I don't think a construction like that exists. Either it's required, or it's

RE: [PATCH] drm/amdkfd: NULL dereference involving create_process()

> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Wednesday, June 14, 2017 6:59 AM > To: Oded Gabbay; Alexey Skidanov > Cc: Deucher, Alexander; Koenig, Christian; David Airlie; dri- > de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; kernel- >

[PATCH v3 10/14] drm/i915: prepare scaler for YCBCR420 modeset

To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI ycbcr420 outputs. - Programs PIPE_MISC register for ycbcr420 output. - Adds a new scaler user "HDMI output" to plug-into existing

[PATCH v3 07/14] drm: set output colorspace in AVI infoframe

HDMI source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. As this patch series is adding support for HDMI output modes other than RGB, this patch adds a function in DRM layer, to add the output colorspace information in the AVI

[PATCH v3 12/14] drm/i915: prepare csc unit for YCBCR HDMI output

To support ycbcr HDMI output, we need a pipe CSC block to do the RGB->YCBCR conversion, as the blender output is in RGB. Current Intel platforms have only one pipe CSC unit, so we can either do color correction using it, or we can perform RGB->YCBCR conversion. This function adds a csc handler,

[PATCH v3 14/14] drm/i915/glk: set HDMI 2.0 identifier

This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID handling functions to save lot of work which is specific to HDMI 2.0 sources. Signed-off-by: Shashank Sharma ---

[PATCH v3 13/14] drm/i915: set colorspace for ycbcr outputs

When HDMI output is other than RGB, we have to load the corresponding colorspace of output mode. This patch fills the colorspace of AVI infoframe as per the HDMI output mode. Cc: Ville Syrjala Cc: Ander Conselvan De Oliveira

[PATCH v3 08/14] drm: add helper functions for YCBCR output handling

This patch adds set of helper functions for YCBCR HDMI output handling. These functions provide functionality like: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 mode. - get the highest subsamled ycbcr output. - get the lowest subsamled ycbcr

[PATCH v3 05/14] drm: parse ycbcr 420 deep color information

CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase Cc: Ville Syrjälä

[PATCH v3 06/14] drm: create hdmi output property

HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB - YCBCR 444 - YCBCR 422 - YCBCR 420 This patch adds a drm property "hdmi_output_format", using which, a user can specify its preference,

[PATCH v3 09/14] drm/i915: add compute_config for YCBCR outputs

This patch checks encoder level support for HDMI YCBCR outputs. HDMI output mode is a connector property, this patch checks if source and sink can support the HDMI output type selected by user. And if they both can, it commits the hdmi output type into crtc state, for further staging in driver.

[PATCH v3 11/14] drm/i915: prepare pipe for YCBCR output

To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in full blend mode to use the scaler in 5x3 ratio (bits 26 and 27) This patch: - Adds definition of these bits. - Programs PIPEMISC

Re: [PATCH v4 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

On Fri, Mar 24, 2017 at 08:51:31AM +0800, Chris Zhong wrote: > The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and > connected to DSI using four lanes. > > Signed-off-by: Chris Zhong > Reviewed-by: Brian Norris > --- > > Changes in

Re: [PATCH v2 1/4] drm/panel: simple: add support for NEC NL12880B20-05

On Thu, Jun 08, 2017 at 08:07:55PM +0200, Lucas Stach wrote: > This adds support for the NEC LCD Technologies, Ltd. 12.1" > WXGA (1280x800) LVDS TFT LCD panel, which can be supported > by the simple panel driver. > > Signed-off-by: Lucas Stach > --- > v2: new patch in V2

Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel

On Tue, Apr 25, 2017 at 01:18:35PM -0300, Marco Franchi wrote: > Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) > TFT with Touch-Panel. > > Datasheet available at: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf > > Seiko 43WVF1G panel has two power supplies: AVDD and

Re: [PATCH 2/3] drm/panel: S6E3HA2 needs backlight code

On Wed, Apr 19, 2017 at 07:59:18PM +0200, Arnd Bergmann wrote: > The new S6E3HA2 driver fails to link when backlight is disabled: > > ERROR: "backlight_device_register" > [drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined! > ERROR: "backlight_device_unregister" >

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

On Wed, Jun 14, 2017 at 08:11:18PM +0200, Maarten Lankhorst wrote: > Op 14-06-17 om 16:52 schreef Ville Syrjälä: > > On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote: > >> Moving the wait to a helper allows callers outside of the core to > >> wait for pending updates to complete.

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

Op 14-06-17 om 16:52 schreef Ville Syrjälä: > On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote: >> Moving the wait to a helper allows callers outside of the core to >> wait for pending updates to complete. >> >> This can be used to prevent races against nonblocking modesets. >>

Re: [PATCH 3/3] drm/panel: add backlight dependency for sitronix-st7789v

On Wed, Apr 19, 2017 at 08:03:08PM +0200, Arnd Bergmann wrote: > Without the dependency, we run into a link error: > > drivers/gpu/drm/panel/panel-sitronix-st7789v.o: In function `st7789v_probe': > panel-sitronix-st7789v.c:(.text.st7789v_probe+0xc0): undefined reference to >

Re: [PATCH] drm/msm: Separate locking of buffer resources from struct_mutex

On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra wrote: > Buffer object specific resources like pages, domains, sg list > need not be protected with struct_mutex. They can be protected > with a buffer object level lock. This simplifies locking and > makes it easier

  1   2   >