Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On Tue, Jun 27, 2017 at 10:51 PM, Jeff Kirsher wrote: > This was submitted and accepted into David Miller's net-next tree. I can > see if Dave can pull it into his net tree. DOes stable need to pick this > up as well? Nah if it landed somewhere at least I'm happy,

RE: xilinx_drm and atomic modesetting

Hi Jean-Francois, As you noted, the Xilinx DRM driver in Xilinx tree is missing many mainline features including the atomic mode setting and needs some restructuring. Please feel free to send patches to Xilinx git-dev, but note that we are also developing / cleaning up the driver internally at

Re: [PATCH v4 1/6] drm/stm: ltdc: Add panel-bridge support

On 06/19/2017 09:58 PM, Philippe CORNU wrote: Add the panel-bridge support for both panels & bridges (used by DSI host & HDMI/LVDS bridges). Reviewed-by: Archit Taneja Signed-off-by: Philippe CORNU --- drivers/gpu/drm/stm/Kconfig | 2 +-

[PATCH 5/5] drm/amdgpu: Don't force BOs into visible VRAM for page faults

There is no need for page faults to force BOs into visible VRAM if it's full, and the time it takes to do so is great enough to cause noticeable stuttering. Add GTT as a possible placement so that if visible VRAM is full, page faults move BOs to GTT instead of evicting other BOs from VRAM.

[PATCH 3/5] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo

Signed-off-by: John Brooks --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++ 3 files changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h

[PATCH 2/5] drm/amdgpu: Throttle visible VRAM moves separately

The BO move throttling code is designed to allow VRAM to fill quickly if it is relatively empty. However, this does not take into account situations where the visible VRAM is smaller than total VRAM, and total VRAM may not be close to full but the visible VRAM segment is under pressure. In such

[PATCH 1/5] drm/amdgpu: Add vis_vramlimit module parameter

Allow specifying a limit on visible VRAM via a module parameter. This is helpful for testing performance under visible VRAM pressure. v2: Add cast to 64-bit (Christian König) Signed-off-by: John Brooks Reviewed-by: Michel Dänzer Reviewed-by:

[PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace, it should only be treated as a hint to initially place a BO somewhere CPU accessible, rather than having a permanent effect on BO placement. Instead of the flag being set in stone at BO creation, set the flag when a page

[PATCH v2] Visible VRAM Management Improvements

Changes in this version: - Dropped former patch 1 ("Separate placements and busy placements") as it was no longer necessary - Dropped former patch 4 ("Don't force BOs into visible VRAM if they can go to GTT instead") as it was unnecessary and had too many side effects (Thanks Christian) -

[Bug 101584] clover: ethminer -G --benchmark: ring buffer overflow, GPU faults

https://bugs.freedesktop.org/show_bug.cgi?id=101584 --- Comment #1 from Christoph Haag --- Created attachment 132290 --> https://bugs.freedesktop.org/attachment.cgi?id=132290=edit without X Thanks to a tip from tom stellard I tried it without X (after exiting sddm).

[Bug 101561] [bisected] [llvm] Blue color shift on videos in MPV when using vo=opengl[-hq]

https://bugs.freedesktop.org/show_bug.cgi?id=101561 Nick Sarnie changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 101594] Blender doesn't detect OpenCL with Clover

https://bugs.freedesktop.org/show_bug.cgi?id=101594 --- Comment #2 from Luke A. Guest --- Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform Version

Re: [PATCH 00/13] fbdev locking rework and deferred setup, take 2

On Tue, Jun 27, 2017 at 7:59 AM, Daniel Vetter wrote: > > Thanks to Liviu's help I realized that I fumbled the locking rework > completely. > This one here should be better, but somehow I'm having a real bad day today > and > I spent all day typing shit code, and then

Re: [PATCH] libdrm: add drm syncobj create/destroy/import/export

Dave Airlie writes: > From: Dave Airlie > > These ioctls are now in drm next so add the first set of libdrm APIs. > > Signed-off-by: Dave Airlie It took me a bit of digging to understand the functional difference between

Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD

On Tue, 2017-06-27 at 16:23 +0300, David Weinehall wrote: > On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote: > > On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote: > > > This patch adds option to enable dynamic backlight for eDP > > > panel that supports

[PATCH 7/8] drm: Add old state pointer to CRTC .enable() helper function

The old state is useful for drivers that need to perform operations at enable time that depend on the transition between the old and new states. While at it, rename the operation to .atomic_enable() to be consistent with .atomic_disable(), as the .enable() operation is used by atomic helpers

[PATCH 3/8] drm: qxl: Remove unused CRTC .dpms() helper operation

The CRTC .dpms() helper operation is called by the atomic helpers only when no .prepare(), .atomic_disable() or .disable() operation is provided. As the qxl driver provides a .disable() operation, the .dpms() operation is unused and can be removed. Signed-off-by: Laurent Pinchart

[PATCH 8/8] drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()

The CRTC .disable() helper operation is deprecated for atomic drivers, the new .atomic_disable() helper operation being preferred. Convert all atomic drivers to .atomic_disable() to avoid cargo-cult use of .disable() in new drivers. Signed-off-by: Laurent Pinchart

[PATCH 5/8] drm: vmwgfx: Remove unneeded CRTC .prepare() helper operation

The CRTC .prepare() helper operation is part of the legacy helpers and is deprecated in favour of the .disable() helper operation. As the vmwgfx driver provides a .disable() helper operation, and as the .prepare() helper operation implementation is empty, we can remove it. Signed-off-by: Laurent

[PATCH 6/8] drm: vmwgfx: Replace CRTC .commit() helper operation with .enable()

The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. Replace the .commit() helper operation with .enable() in the driver. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 6

[PATCH 2/8] drm: arcpgu: Remove CRTC .prepare() helper operation

The CRTC helper .prepare() operation is legacy code, the atomic helpers prefer the .disable() operation. As the arcpgu driver implements the .disable() and .prepare() operations identicallly, .prepare() can be removed. Signed-off-by: Laurent Pinchart

[PATCH 4/8] drm: qxl: Replace CRTC .commit() helper operation with .enable()

The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. Replace the .commit() helper operation with .enable() in the driver. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/qxl/qxl_display.c | 4 ++--

[PATCH 1/8] drm: arcpgu: Remove CRTC .commit() helper operation

The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. As the arcpgu driver implements the .enable() operation, .commit() is never used and can be removed. Signed-off-by: Laurent Pinchart ---

[PULL] drm-misc-next-fixes

Hi Dave, When I said I had ~6 changes yesterday, I was lying. 3 of those changes were included in the final misc-next pull and already exist in your tree. So then there were 3. All quite simple, nothing to write home about. You'll notice the unsightly backmerges below, this was due to the

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On Wed, 2017-06-28 at 05:28 +1000, Dave Airlie wrote: > On 20 June 2017 at 18:49, Daniel Vetter wrote: > > On Wed, Jun 07, 2017 at 01:07:33AM +, Brown, Aaron F wrote: > > > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] > > > > On Behalf > > > > Of Jeff

Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

On Mon, Jun 26, 2017 at 6:26 PM, Logan Gunthorpe wrote: > Hi Jyri, > > Thanks for the ack. However, I'm reworking this patch set to use the > include/linux/io-64-nonatomic* headers which will explicitly devolve > into two 32-bit transfers. It's not clear whether this is

[PATCH 7/8] drm: Add old state pointer to CRTC .enable() helper function

The old state is useful for drivers that need to perform operations at enable time that depend on the transition between the old and new states. While at it, rename the operation to .atomic_enable() to be consistent with .atomic_disable(), as the .enable() operation is used by atomic helpers

[PATCH 4/8] drm: qxl: Replace CRTC .commit() helper operation with .enable()

The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. Replace the .commit() helper operation with .enable() in the driver. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/qxl/qxl_display.c | 4 ++--

[PATCH 8/8] drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()

The CRTC .disable() helper operation is deprecated for atomic drivers, the new .atomic_disable() helper operation being preferred. Convert all atomic drivers to .atomic_disable() to avoid cargo-cult use of .disable() in new drivers. Signed-off-by: Laurent Pinchart

[PATCH 2/8] drm: arcpgu: Remove CRTC .prepare() helper operation

The CRTC helper .prepare() operation is legacy code, the atomic helpers prefer the .disable() operation. As the arcpgu driver implements the .disable() and .prepare() operations identicallly, .prepare() can be removed. Signed-off-by: Laurent Pinchart

[PATCH 6/8] drm: vmwgfx: Replace CRTC .commit() helper operation with .enable()

The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. Replace the .commit() helper operation with .enable() in the driver. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 6

[PATCH 3/8] drm: qxl: Remove unused CRTC .dpms() helper operation

The CRTC .dpms() helper operation is called by the atomic helpers only when no .prepare(), .atomic_disable() or .disable() operation is provided. As the qxl driver provides a .disable() operation, the .dpms() operation is unused and can be removed. Signed-off-by: Laurent Pinchart

[PATCH 5/8] drm: vmwgfx: Remove unneeded CRTC .prepare() helper operation

The CRTC .prepare() helper operation is part of the legacy helpers and is deprecated in favour of the .disable() helper operation. As the vmwgfx driver provides a .disable() helper operation, and as the .prepare() helper operation implementation is empty, we can remove it. Signed-off-by: Laurent

[PATCH 0/8] Cleanup CRTC .enable()/.disable() cargo-cult

Hello, The atomic helpers favour the .enable() and .atomic_disable() CRTC helper operations, but still support the legacy .prepare(), .commit(), .disable() and .dpms() operations. Some drivers have been updated, but most still use various combination of new and legacy operations, leading to

[PATCH 1/8] drm: arcpgu: Remove CRTC .commit() helper operation

The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. As the arcpgu driver implements the .enable() operation, .commit() is never used and can be removed. Signed-off-by: Laurent Pinchart ---

[PATCH 5/8] drm/vc4: Delay DSI host registration until the panel has probed.

The vc4 driver was unusual in that it was delaying the panel lookup until the attach step, while most DSI hosts will -EPROBE_DEFER until they get a panel. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_dsi.c | 40 1 file changed,

[PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.

When a mipi_dsi_host is registered, the DT is walked to find any child nodes with compatible strings. Those get registered as DSI devices, and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes. There is one special case currently, the adv7533 bridge, where the bridge probes

[PATCH 8/8] drm/panel: Add support for the Raspberry Pi 7" Touchscreen.

This driver communicates with the Atmel microcontroller for sequencing the poweron of the TC358762 DSI-DPI bridge and controlling the backlight PWM. v2: Set the same default orientation as the closed source firmware used, which is the best for viewing angle. v3: Rewrite as an i2c client

[PATCH 7/8] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

This doesn't yet cover input, but the driver does get the display working when the firmware is disabled from talking to our I2C lines. Signed-off-by: Eric Anholt Acked-by: Rob Herring --- .../panel/raspberrypi,7inch-touchscreen.txt| 49

[PATCH 3/8] drm/vc4: Use drm_mode_vrefresh() in DSI fixup, in case vrefresh is 0.

I'm not sure what changed where I started getting vrefresh=0 from the mode to be fixed up. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_dsi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c

[PATCH 2/8] drm/vc4: Fix misleading name of the continuous flag.

The logic was all right in the end, the name was just backwards. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_dsi.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c index

[PATCH 4/8] drm/bridge: Add a devm_ allocator for panel bridge.

This will let drivers reduce the error cleanup they need, in particular the "is_panel_bridge" flag. Signed-off-by: Eric Anholt --- drivers/gpu/drm/bridge/panel.c | 30 ++ include/drm/drm_bridge.h | 3 +++ 2 files changed, 33 insertions(+)

[PATCH 1/8] drm/vc4: Fix DSI T_INIT timing.

The DPHY spec requires a much larger T_INIT than I was specifying before. In the absence of clear specs from the slave of what their timing is, just use the value that the firmware was using. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_dsi.c | 12 +++- 1

[PATCH 0/8] RPi touchscreen panel driver v4

The review for v3 was basically "no, the panel should probe first so that we have the connector by the time KMS is done initializing." To do this, I needed to be able to register the custom (non-OF-generated) DSI device without the host being present (patch 6). Also check out patch 4 for a new

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On 20 June 2017 at 18:49, Daniel Vetter wrote: > On Wed, Jun 07, 2017 at 01:07:33AM +, Brown, Aaron F wrote: >> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf >> > Of Jeff Kirsher >> > Sent: Tuesday, June 6, 2017 1:46 PM >> > To: David Miller

[Bug 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

https://bugzilla.kernel.org/show_bug.cgi?id=196197 --- Comment #2 from Andreas Brogle (an...@ok.de) --- Hello, Sorry, I've read the git dokumentation half the day, anyway I don't understand how bisect works and how to use it. Is the following what you need ? # git bisect log git bisect start

Re: [PATCH 13/13] drm/atomic-helper: Realign function parameters

On 2017-06-27 10:59 AM, Daniel Vetter wrote: > Too jarring. > > Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers > (v2)") > Cc: Andrey Grodzovsky > Cc: Alex Deucher > Signed-off-by: Daniel Vetter

[Bug 101572] glMemoryBarrier is backwards

https://bugs.freedesktop.org/show_bug.cgi?id=101572 --- Comment #5 from Matias N. Goldberg --- (btw unsetting the FBO indeed fixes the issue) -- You are receiving this mail because: You are the assignee for the bug.___

[Bug 101572] glMemoryBarrier is backwards

https://bugs.freedesktop.org/show_bug.cgi?id=101572 --- Comment #4 from Matias N. Goldberg --- After careful thought; I realized I don't need to switch to a dummy FBO; just unset the current one. That DOES make sense to me as while the FBO is bound and I'm executing

[Bug 101572] glMemoryBarrier is backwards

https://bugs.freedesktop.org/show_bug.cgi?id=101572 --- Comment #3 from Matias N. Goldberg --- I rather be told that I am wrong in how to interpret glMemoryBarrier, and that I should be calling glMemoryBarrier( GL_FRAMEBUFFER_BARRIER_BIT ); because this and that. --

[Bug 101572] glMemoryBarrier is backwards

https://bugs.freedesktop.org/show_bug.cgi?id=101572 --- Comment #2 from Matias N. Goldberg --- That can't be right. You're suggesting that in order to synchronize writes from FBO with a Compute Shader I am going to dispatch (which btw the Compute Shader is accessing

RE: [PATCH 13/13] drm/atomic-helper: Realign function parameters

> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] > Sent: Tuesday, June 27, 2017 11:00 AM > To: DRI Development > Cc: Intel Graphics Development; Daniel Vetter; Grodzovsky, Andrey; > Deucher, Alexander; Daniel Vetter > Subject: [PATCH 13/13] drm/atomic-helper:

[Bug 101594] Blender doesn't detect OpenCL with Clover

https://bugs.freedesktop.org/show_bug.cgi?id=101594 --- Comment #1 from Vedran Miletić --- Can you post your clinfo? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #11 from omegap...@startmail.com --- Wow, thats one hell of a lot of output :) I'll keep running with 'drm.debug=0x01' until I get the problem next, thanks. I'm on Devuan Testing rather than Ubuntu (RE the Padoka PPA) - looking at

[Bug 100242] radeon buffer allocation failure during startup of Factorio

https://bugs.freedesktop.org/show_bug.cgi?id=100242 --- Comment #11 from tnmailingli...@gmail.com --- The game starts up fine without a crash now and handles the out of memory error gracefully like before. Thanks! -- You are receiving this mail because: You are the assignee for the

[PATCH 11/13] drm/exynos: Remove custom FB helper deferred setup

From: Thierry Reding The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already. Cc: Inki Dae Cc: Joonyoung Shim

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote: > Op 27-06-17 om 09:37 schreef Daniel Vetter: > > On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: > >> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote: > >>> Problem : While running IGT kms_atomic_transition test

[PATCH 08/13] drm/fb-helper: Stop using mode_config.mutex for internals

Those are now all protected using fb_helper->lock. v2: We still need to hold mode_config.mutex right around calling connector->fill_modes. v3: I forgot to hold mode_config.mutex while looking at connector->status and the mode list. Also, we need to patch up the i915 ->initial_config callback to

[PATCH 12/13] drm/hisilicon: Remove custom FB helper deferred setup

From: Thierry Reding The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong Cc: Chen Feng

[PATCH 10/13] drm/fb-helper: Support deferred setup

FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a matching mode. The fallback is in place

[PATCH 13/13] drm/atomic-helper: Realign function parameters

Too jarring. Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers (v2)") Cc: Andrey Grodzovsky Cc: Alex Deucher Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 24

[PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths

Like with panning and modesetting, and like with those, stick with simple drm_modeset_locking_all for the legacy path, and the full atomic dance for atomic drivers. This means a bit more boilerplate since setting up the atomic state machinery is rather verbose, but then this is shared code for

[PATCH 07/13] drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy

Same game as with the panning function, use drm_modeset_lock_all for legacy paths, and a proper acquire ctx w/w mutex dance for atomic. Cc: John Stultz Cc: Thierry Reding Signed-off-by: Daniel Vetter ---

[PATCH 06/13] drm/fb-helper: Push locking into pan_display_atomic|legacy

For the legacy path we'll keep drm_modeset_lock_all, for the atomic one we drop the use of the magic implicit context and wire it up properly. Cc: John Stultz Cc: Thierry Reding Signed-off-by: Daniel Vetter ---

[PATCH 01/13] drm/fb-helper: Push down modeset lock into FB helpers

From: Thierry Reding Move the modeset locking from drivers into FB helpers. v2: Also handle intel_connector_add_to_fbdev. Tested-by: John Stultz Signed-off-by: Thierry Reding (v1) Signed-off-by: Daniel Vetter

[PATCH 04/13] drm/fb-helper: Push locking in fb_is_bound

That function only needs to take the individual crtc locks, not all the kms locks. Push down the locking and then minimize it. Cc: John Stultz Cc: Thierry Reding Signed-off-by: Daniel Vetter ---

[PATCH 05/13] drm/fb-helper: Drop locking from the vsync wait ioctl code

Like with the drm-native vblank wait ioctl we can entirely rely on the spinlocks in drm_vblank.c, no need at all to take expensive mutexes. The only reason we had to take mode_config.mutex was to protect the fbdev helper's data-structures, but that's now done by fb_helper->lock. Cc: John Stultz

[PATCH 02/13] drm/i915: Drop FBDEV #ifdev in mst code

Since commit a03fdcb1863297481a4b817c2a759cafcbdfa0ae Author: Archit Taneja Date: Wed Aug 5 12:28:57 2015 +0530 drm: Add top level Kconfig option for DRM fbdev emulation this is properly handled using dummy functions. This essentially undoes commit

[PATCH 00/13] fbdev locking rework and deferred setup, take 2

Hi all, Thanks to Liviu's help I realized that I fumbled the locking rework completely. This one here should be better, but somehow I'm having a real bad day today and I spent all day typing shit code, and then making it worse. This here seems to work at first glance, but please test and review

[PATCH 03/13] drm/fb-helper: Add top-level lock

From: Thierry Reding Introduce a new top-level lock for the FB helper code. This will allow better locking granularity and avoid the need to abuse modeset locking for this purpose instead. This patch just adds the new lock everywhere we currently grab mode_config->mutex

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Op 27-06-17 om 09:37 schreef Daniel Vetter: > On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: >> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote: >>> Problem : While running IGT kms_atomic_transition test suite i encountered >>> a hang in drmHandleEvent immediately following an

[PATCH 4.11 52/58] drm: Fix GETCONNECTOR regression

4.11-stable review patch. If anyone has any objections, please let me know. -- From: Daniel Vetter commit e94ac3510b6a0f696f2c442c4fc4051c8101ef12 upstream. In commit 91eefc05f0ac71902906b2058360e61bd25137fe Author: Daniel Vetter

[Bug 92715] [IGT] [BYT-M/KBL/BSW/BXT/BDW] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 Elizabeth changed: What|Removed |Added Status|NEW

[Bug 92715] [IGT] [BYT-M/KBL/BSW/BXT/BDW] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 Elizabeth changed: What|Removed |Added Status|NEEDINFO

Re: [PATCH] drm/i915: Fix an error checking test

Quoting Christophe JAILLET (2017-06-27 06:38:54) > 'dma_buf_vmap' returns NULL on error, not an error pointer. > > Fixes: 6cca22ede8a4 ("drm/i915: Add some mock tests for dmabuf interop") > Signed-off-by: Christophe JAILLET Thanks for the fix, reviewed and pushed.

Re: [PATCH] drm/i915: Print pwm device-name when using pwm for backlight control

Hi, On 06/27/2017 11:52 AM, Ville Syrjälä wrote: On Fri, Jun 23, 2017 at 09:42:44AM +0200, Hans de Goede wrote: On Bay Trail devices either the Crystal Cove PMIC's pwm or the LPSS' pwm is used to control the backlight. Other drivers take core of providing a backlight_pwm alias through

Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD

On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote: > On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote: > > This patch adds option to enable dynamic backlight for eDP > > panel that supports this feature via DPCD register and > > set minimum / maximum brightness

xilinx_drm and atomic modesetting

Hi guys, Note: I was a total DRM newbie at the beginning of this exercise. Now I would say I'm just newbie. ;) I am trying to implement our lvds panel using xilinx_drm on zynqmp. We are composing our pipeline starting with the xilinx-vdma, then a few logic parts from the ALI3 on zedboard ref

Re: [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote: > 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

Re: [PATCH v5 7/7] drm: create hdmi output property

On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Simplify commit tracking locking

On Wed, Jun 21, 2017 at 10:30:51AM -0400, Sean Paul wrote: > On Wed, Jun 21, 2017 at 11:16:27AM +0200, Daniel Vetter wrote: > > The crtc->commit_lock only protects commit_list and commit_entry. If > > we chase the pointer from the drm_atomic_state update structure, then > > we don't need any locks

Re: [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks

On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote: > CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. > This block contains a map of indexes of CEA modes, which can > support YCBCR 420 output also. To avoid multiple parsing of same > CEA block, let's parse the sink

Re: [RESEND-CI v4 05/15] drm/edid: parse ycbcr 420 deep color information

On Wed, Jun 21, 2017 at 04:04:03PM +0530, Shashank Sharma wrote: > 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

Re: [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID

On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote: > HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. > CEA-861-F adds two new blocks in EDID's CEA extension blocks, > to provide information about sink's YCBCR420 output capabilities. > > These blocks are: > > -

Re: [RESEND-CI v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)

On Wed, Jun 21, 2017 at 04:04:01PM +0530, Shashank Sharma wrote: > CEA-861-F specs defines new video modes to be used with > HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to > 1-107. > > Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now > to be able to parse new

[Bug 101499] Black screen when detaching HDMI cable (AMD A10-9620P)

https://bugs.freedesktop.org/show_bug.cgi?id=101499 Carlo Caione changed: What|Removed |Added Attachment #132130|0 |1 is obsolete|

[GIT PULL] mediatek drm next for 4.13

Hi, Dave: This include new color format support and some fixups. Please kindly let me know if there is any problem. Regards, CK The following changes since commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b: Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000) are available in

Re: [PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

On 27.06.2017 11:13, Inki Dae wrote: > Hi Andrzej, > > 2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글: >> Hi Shuah, >> >> >> On 24.06.2017 02:56, Shuah Khan wrote: >>> Fix to call of_node_put() right after of_drm_find_bridge() instead of >>> holding on to it until exynos_dsi_remove(). >> I think the

Re: [Nouveau] [PATCH] drm/nouveau/therm: fix spelling mistake on array thresolds

On 27/06/17 11:08, Colin King wrote: From: Colin Ian King Array thresolds should be named thresholds, rename it. Also make it static static const char * const Signed-off-by: Colin Ian King Thanks for doing this, Reviewed-by: Martin Peres

Re: [PATCH] drm/i915: Print pwm device-name when using pwm for backlight control

On Fri, Jun 23, 2017 at 09:42:44AM +0200, Hans de Goede wrote: > On Bay Trail devices either the Crystal Cove PMIC's pwm or the LPSS' > pwm is used to control the backlight. Other drivers take core of > providing a backlight_pwm alias through pwm_add_table, but it is > still useful to know which

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

On 06/27/17 12:27, Hans Verkuil wrote: > On 27/06/17 11:14, Tony Lindgren wrote: >> * Hans Verkuil [170627 01:39]: >>> On 26/06/17 13:07, Tony Lindgren wrote: Tomi, * Tomi Valkeinen [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil

Re: [PATCH][drm-next] drm/i915: fix spelling mistake: "CouarPoint" -> "CougarPoint"

On Tue, Jun 27, 2017 at 08:30:09AM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in DRM_DEBUG_KMS message > > Signed-off-by: Colin Ian King I have this already queued for 4.14, from Ville. I'll show up

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

On 27/06/17 11:14, Tony Lindgren wrote: > * Hans Verkuil [170627 01:39]: >> On 26/06/17 13:07, Tony Lindgren wrote: >>> Tomi, >>> >>> * Tomi Valkeinen [170428 04:15]: On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

On 06/27/17 12:14, Tony Lindgren wrote: > * Hans Verkuil [170627 01:39]: >> On 26/06/17 13:07, Tony Lindgren wrote: >>> Tomi, >>> >>> * Tomi Valkeinen [170428 04:15]: On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil

Re: [PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

Hi Andrzej, 2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글: > Hi Shuah, > > > On 24.06.2017 02:56, Shuah Khan wrote: >> Fix to call of_node_put() right after of_drm_find_bridge() instead of >> holding on to it until exynos_dsi_remove(). > > I think the current implementation is OK, node is get in

[Bug 101572] glMemoryBarrier is backwards

https://bugs.freedesktop.org/show_bug.cgi?id=101572 Nicolai Hähnle changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 98619] amdgpu 0000:01:00.0: GPU fault detected: 146 0x09d88404

https://bugs.freedesktop.org/show_bug.cgi?id=98619 --- Comment #9 from Nicolai Hähnle --- Since this is almost certainly an entirely different problem -- looks like you're using Vulkan -- could you please open a separate bug report? Thanks. -- You are receiving this mail

[Bug 101484] [regression, bisected] Steam fails to render content, if mesa is compiled with -O2 -march=haswell

https://bugs.freedesktop.org/show_bug.cgi?id=101484 --- Comment #12 from Mika --- Hi, I tried with both clang and gcc on Haswell / Pitcairn with "-O2 -march=native", and I obtained the very same broken display clang version 5.0.0 (trunk 306114) gcc version 7.1.1

[Bug 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

https://bugzilla.kernel.org/show_bug.cgi?id=196197 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- Can you bisect between 4.10 and 4.11? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing

[Bug 196197] New: [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

https://bugzilla.kernel.org/show_bug.cgi?id=196197 Bug ID: 196197 Summary: [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) Product: Drivers Version: 2.5 Kernel Version:

  1   2   >