[PATCH 4/4] drm/i915: Implement Link Rate fallback on Link training failure

On Tue, 06 Dec 2016, Manasi Navare wrote: > If link training at a link rate optimal for a particular > mode fails during modeset's atomic commit phase, then we > let the modeset complete and then retry. We save the link rate > value at which link training failed, update the link status property >

[PATCH 3/4] drm/i915: Find fallback link rate/lane count

On Tue, 06 Dec 2016, Manasi Navare wrote: > If link training fails, then we need to fallback to lower > link rate first and if link training fails at RBR, then > fallback to lower lane count. > This function finds the next lower link rate/lane count > value after link training failure and limits

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

pp_dpm_sclk -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d019211f/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/7c3010ef/attachment.html>

[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

On Tue, 06 Dec 2016, Manasi Navare wrote: > Sink's capabilities are advertised through DPCD registers and get > updated only on hotplug. So they should be computed only once in the > long pulse handler and saved off in intel_dp structure for the use > later. For this reason two new fields

[Bug 95206] Display port bandwidth regression

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/f74f844f/attachment-0001.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/1caa301d/attachment.html>

[PATCH RFC 0/3] drm/bridge: adjust bridge module's refcount and more

There has been no comments to these patches, so I guess there are no major objections. I can go forward with this, and I think a similar job should be done for drm_panel too. But I wonder if this should be done for 4.10 any more? Best regards, Jyri On 12/01/16 17:52, Jyri Sarha wrote: > Note!

[Bug 80419] XCOM: Enemy Unknown Causes lockup

9d6). Will try to crash it again tomorrow, but looks promising. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/e6415f16/attachment.html>

[RFC PATCH 0/3] staging: remove fbdev drivers

On Wednesday 23 November 2016 09:12 AM, Tomi Valkeinen wrote: > On 23/11/16 10:52, Greg Kroah-Hartman wrote: >> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote: >>> Hi, >>> >>> Since the fbdev framework is in maintenance mode and all new display drivers >>> should be made with the

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

If you are right about texture streaming, the cso commit might fix it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208

[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable

with LLVM 3.9 and only use Mesa git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/267edb3e/attachment.html>

[PATCH] drm/mxsfb: use bus_format to determine LCD bus width

On 2016-12-08 15:33, Marek Vasut wrote: > On 12/08/2016 11:52 PM, Stefan Agner wrote: >> The LCD bus width does not need to align with the pixel format. The >> LCDIF controller automatically converts between pixel formats and >> bus width by padding or dropping LSBs. >> >> The DRM subsystem has

[Bug 98777] GPU lockup in Guns of Icarus Online

was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/a584b733/attachment.html>

[Bug 98776] [regression] Rendering glitches in Life Is Strange

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161208/55a03bed/attachment-0001.html>

[PATCH v7 3/4] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure and limits the max link_rate and lane_count values to these

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ee7d730a/attachment.html>

[PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests

The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color

[PATCH 4/5] drm: Add definitions for DP compliance Video pattern tests

v2: * Add all the other DP Complianec TEST register defs (Jani Nikula) Cc: dri-devel at lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by: Manasi Navare --- include/drm/drm_dp_helper.h | 58 + 1 file changed, 58

[PATCH 3/5] drm/i915: Fixes to support DP Compliance EDID tests

This patch addresses a few issues from the original patch for DP Compliance EDID test support submitted by Todd Previte Video Mode requested in the EDID test handler for the EDID Read test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec. Signed-off-by: Manasi Navare Cc: Jani Nikula

[PATCH 2/5] drm/i915: Add support for DP link training compliance

This patch adds support to handle automated DP compliance link training test requests. This patch has been tested with Unigraf DPR-120 DP Compliance device for testing Link Training Compliance. After we get a short pulse Compliance test request, test request values are read and hotplug uevent is

[PATCH 1/5] drm/i915: Move all the DP compliance data to a separate struct

This patch does not change anything functionally, just cleans up the DP compliance related variables and stores them all together in a separate struct intel_dp_compliance. There is another struct intel_dp_compliance_data to store all the test data. This makes it easy to reset the compliance

[PATCH 0/5] Add Automation Support for DP Compliance Testing (Rev 2)

This addresses all the review comments from the earlier patch series: https://patchwork.freedesktop.org/series/15771/ DP 1.2 compliance testing can be acheived using DPR-120's CTS suite. This compliance unit sends a short pulse to initiate link training and video pattern generation compliance

[PATCH] linux/types.h: enable endian checks for all sparse builds

On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote: > On 12/07/16 21:54, Michael S. Tsirkin wrote: > > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote: > >> Additionally, there are notable exceptions to the rule that most drivers > >> are endian-clean, e.g.

[PATCH] drm: zte: add overlay plane support

On Thu, Dec 08, 2016 at 11:12:41AM +0800, Shawn Guo wrote: > +static void zx_vl_plane_atomic_update(struct drm_plane *plane, > + struct drm_plane_state *old_state) > +{ > + struct zx_plane *zplane = to_zx_plane(plane); > + struct drm_framebuffer *fb =

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

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d9b22fd3/attachment.html>

[PATCH 2/2] ASoC: hdmi-codec: add channel mapping control

Add user interface to provide channel mapping. In a first step this control is read only. As TLV type, the control provides all configurations available for HDMI sink(ELD), and provides current channel mapping selected by codec based on ELD and number of channels specified by user on open. When

[PATCH 1/2] DRM: add help to get ELD speaker allocation

Add helper to allow users to retrieve the speaker allocations without knowledge of the ELD structure. Signed-off-by: Arnaud Pouliquen --- include/drm/drm_edid.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index

[PATCH 0/2] Generic HDMI codec: Add channel mapping control

Aim of this patch is to add 'Playback Channel Map' control to export audio capabilities in term of HDMI sink speakers allocation. This patch follow discussion initiates here: [RFC] ASOC: HDMI audio info frame speaker allocation http://www.spinics.net/lists/alsa-devel/msg57363.html The code is

[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable

s://lists.freedesktop.org/archives/dri-devel/attachments/20161208/0868c983/attachment.html>

[PATCH v4 1/4] drm: Add a new connector atomic property for link status

On Tue, 06 Dec 2016, Manasi Navare wrote: > At the time userspace does setcrtc, we've already promised the mode > would work. The promise is based on the theoretical capabilities of > the link, but it's possible we can't reach this in practice. The DP > spec describes how the link should be

[pull] radeon and amdgpu drm-next-4.10

Hi Dave, Misc fixes and cleanups for 4.10. Highlights: - Cursor fixes for radeon and amdgpu - DPM fixes for some new SI variants - Powerplay fixes - Clock and powergating fixes The following changes since commit 197aa6ed522cc44710687d3b02dd4e4573991416: Merge branch 'exynos-drm-next' of

[RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 08 Dec 2016, Geert Uytterhoeven wrote: > On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter wrote: >> If you're this good at mainting gpu and display subsystems, maybe you >> want to take over? > > No please ;-) Now that is indeed the right answer, and the attitude we're looking for! Being

[RFC] Using DC in amdgpu for upcoming GPU

On Thu, Dec 08, 2016 at 04:41:52PM +0100, Christian König wrote: > Am 08.12.2016 um 16:34 schrieb Daniel Vetter: > > On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote: > > > Hi Daniel, > > > > > > just a quick clarification in-line about "validation" inside > > > atomic_commit. > >

[Bug 89534] radeonsi GPU lockup / crash with wine

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/e7923314/attachment.html>

[PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.

On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote: > The current api doesn't take into account that whenever properties like > rotation or z-pos change we have to wait for vblank. To make sure > that we wait correctly, err on the side of caution and wait whenever > a plane is added

[RFC] Using DC in amdgpu for upcoming GPU

Am 08.12.2016 um 16:34 schrieb Daniel Vetter: > On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote: >> Hi Daniel, >> >> just a quick clarification in-line about "validation" inside atomic_commit. >> >> On 2016-12-08 04:59 AM, Daniel Vetter wrote: >>> Hi Harry, >>> >>> On Wed, Dec 07,

[Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.

On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote: > Atomic drivers may set properties like rotation on the same fb, which > may require a call to prepare_fb even when framebuffer stays identical. > > Instead of handling all the special cases in the core, let the driver > decide

[PATCH 3/6] drm/atomic: Clean up wait_for_vblanks

On Thu, Dec 08, 2016 at 02:45:26PM +0100, Maarten Lankhorst wrote: > Stop relying on a per crtc_state last_vblank_count, we know in advance > how many there can be. Also stop re-using new_crtc_state->enable, > we can now simply set a bitmask with crtc_crtc_mask. > --- >

[Intel-gfx] [PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.

On Thu, Dec 08, 2016 at 02:45:24PM +0100, Maarten Lankhorst wrote: > When DPMS was introduced to atomic, vblanks only worked when the crtc > was enabled and active. wait_for_vblanks were not converted to check for > crtc_state->active, which may cause an attempt for vblank_get to fail. > > This

[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video

was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ab0dd888/attachment.html>

[RFC] Using DC in amdgpu for upcoming GPU

On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote: > Hi Daniel, > > just a quick clarification in-line about "validation" inside atomic_commit. > > On 2016-12-08 04:59 AM, Daniel Vetter wrote: > > Hi Harry, > > > > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: > >

[Bug 97166] lockup during gameplay of Batman series of games

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/85522ad9/attachment.html>

[Bug 89534] radeonsi GPU lockup / crash with wine

bugs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/cbe29737/attachment-0001.html>

[Intel-gfx] [PATCH v4 1/4] drm: Add a new connector atomic property for link status

On Thu, Dec 08, 2016 at 05:05:54PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > At the time userspace does setcrtc, we've already promised the mode > > would work. The promise is based on the theoretical capabilities of > > the link, but it's possible we can't reach

[RFC PATCH 0/3] staging: remove fbdev drivers

[back from my walk, the sunset here is stellar ;-)] On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote: > Hi Thomas, > > On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni > wrote: > > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote: > >> > Wut. We have like 20+ small

[Bug 80419] XCOM: Enemy Unknown Causes lockup

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d6c92ded/attachment.html>

[RFC PATCH 0/3] staging: remove fbdev drivers

Hi Thomas, On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni wrote: > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote: >> > Wut. We have like 20+ small atomic drivers nowdays. >> >> That's fast! Only two weeks ago you said: >> >> | Bummer, they still haven't landed. But afaik there's

[RFC PATCH 0/3] staging: remove fbdev drivers

Hello, On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote: > > Wut. We have like 20+ small atomic drivers nowdays. > > That's fast! Only two weeks ago you said: > > | Bummer, they still haven't landed. But afaik there's at least 4 of > | them floating around in various places ...

[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video

r the help and it's nice to know that this is still used. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/38c086e4/attachment.html>

[PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon TFT's as an active switching devices. It can be supported by the simple-panel driver. Read the panel edid information; EDID MODE DETAILS name = pixel_clock = 71900

[PATCH v2 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- Changes in v2: None .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644

[RFC PATCH 0/3] staging: remove fbdev drivers

Dear dri-devel folks, My sincere apologies for hitting send on that mail. I got real mad and angry and typed a mail I shouldn't have submitted - pouring oil into flames for shit and giggles just doesn't help anyone, and it detracts from moving things forward and improving the code and drivers and

[RFC PATCH 0/3] staging: remove fbdev drivers

Hi Daniel, On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote: >> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote: >> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: >> >> On Wed, 2016-11-23 at

[Intel-gfx] [PATCH] drm: Take ownership of the dmabuf->obj when exporting

On Thu, Dec 08, 2016 at 03:03:29PM +0200, Joonas Lahtinen wrote: > On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote: > > Currently the reference for the dmabuf->obj is incremented for the > > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace > > interface), but is released in

[RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

On Thu, Dec 08, 2016 at 11:57:25AM +, Robert Bragg wrote: > On Thu, Dec 8, 2016 at 12:17 AM, Daniel Vetter wrote: > > > > On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote: > > > This is still missing corresponding documentation changes, and I haven't > > > moved anything to

[Intel-gfx] [PATCH] drm: Take ownership of the dmabuf->obj when exporting

On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote: > Currently the reference for the dmabuf->obj is incremented for the > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace > interface), but is released in drm_gem_dmabuf_release() (the lowlevel > handler). Improve the symmetry

[RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote: > On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote: > > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: > >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > >> > Since the fbdev framework is

[Bug 99029] VCE VAAPI segfault using ffmpeg

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/78b48604/attachment.html>

[PATCH] drm/panel: simple: specify bus width and flags for EDT displays

The display has a 18-Bit parallel LCD interface, require DE to be active high and data driven by the controller on falling pixel clock edge (display samples on rising edge). Signed-off-by: Stefan Agner --- drivers/gpu/drm/panel/panel-simple.c | 4 1 file changed, 4 insertions(+) diff

[PATCH] drm/mxsfb: use bus_format to determine LCD bus width

The LCD bus width does not need to align with the pixel format. The LCDIF controller automatically converts between pixel formats and bus width by padding or dropping LSBs. The DRM subsystem has the notion of bus_format which allows to determine what bus_formats are supported by the display.

[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video

back to "signed i;" which is enough to repair this regression. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016

[PATCH 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.

Do something similar to vc4, only allow updating the cursor state in-place through a fastpath when the watermarks are unaffected. This will allow cursor movement to be smooth, but changing cursor size or showing/hiding cursor will still fall back so watermarks can be updated. Only moving and

[PATCH 5/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed.

This function is now completely unused, zap it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 35 --- include/drm/drm_atomic_helper.h | 3 --- 2 files changed, 38 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c

[PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.

The current api doesn't take into account that whenever properties like rotation or z-pos change we have to wait for vblank. To make sure that we wait correctly, err on the side of caution and wait whenever a plane is added to state. Signed-off-by: Maarten Lankhorst ---

[PATCH 3/6] drm/atomic: Clean up wait_for_vblanks

Stop relying on a per crtc_state last_vblank_count, we know in advance how many there can be. Also stop re-using new_crtc_state->enable, we can now simply set a bitmask with crtc_crtc_mask. --- drivers/gpu/drm/drm_atomic_helper.c | 29 +++-- include/drm/drm_crtc.h

[PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.

Atomic drivers may set properties like rotation on the same fb, which may require a call to prepare_fb even when framebuffer stays identical. Instead of handling all the special cases in the core, let the driver decide when prepare_fb and cleanup_fb are noops. Signed-off-by: Maarten Lankhorst

[PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.

When DPMS was introduced to atomic, vblanks only worked when the crtc was enabled and active. wait_for_vblanks were not converted to check for crtc_state->active, which may cause an attempt for vblank_get to fail. This is probably harmless, but convert from enable to active anyway.

[PATCH 0/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed

drm_atomic_helpers use framebuffer_changed to skip some vblank waits in case properties don't change. This may skip vblank waits also when properties like rotation are changed. Fix this by always waiting for vblank if planes are added to the state, and always calling prepare_fb even when fb stays

[Bug 99029] VCE VAAPI segfault using ffmpeg

Hardware|Other |x86-64 (AMD64) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/07f867c3/attachment.html>

[Bug 99029] VCE VAAPI segfault using ffmpeg

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/74a34ee1/attachment.html>

[PATCH v5 1/4] drm: Add a new connector atomic property for link status

> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 72fa5b2..34eddb9 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1087,6 +1087,22 @@ int drm_atomic_connector_set_property(struct > drm_connector *connector, >

[GIT PULL] omapdrm fixes for v4.10

(-) -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/a00641ed/attachment.sig>

[PATCH] drm/edid: Don't print an error if the checksum of a CEA block is wrong

It's common to share screens within CI labs, and it's also common for KVM switches to alter the contents of the CEA block but leave the checksum outdated. So in this case, print a debug message instead of an error. References: https://bugs.freedesktop.org/show_bug.cgi?id=98228 Cc: Chris Wilson

[PATCH 4/4] drm/i915: Implement Link Rate fallback on Link training failure

On Thu, Dec 08, 2016 at 11:51:30PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > If link training at a link rate optimal for a particular > > mode fails during modeset's atomic commit phase, then we > > let the modeset complete and then retry. We save the link rate > >

[Intel-gfx] [PATCH 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.

On 8 December 2016 at 13:45, Maarten Lankhorst wrote: > Do something similar to vc4, only allow updating the cursor state > in-place through a fastpath when the watermarks are unaffected. This > will allow cursor movement to be smooth, but changing cursor size or > showing/hiding cursor will

[PATCH 3/4] drm/i915: Find fallback link rate/lane count

On Thu, Dec 08, 2016 at 11:46:02PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > If link training fails, then we need to fallback to lower > > link rate first and if link training fails at RBR, then > > fallback to lower lane count. > > This function finds the next

[RESEND PATCH 2/2] drm/panel: simple: Add support BOE nv101wxmn51

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon TFT's as an active switching devices. It can be supported by the simple-panel driver. Signed-off-by: Caesar Wang --- drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31

[RESEND PATCH 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt

[PATCH] drm/panel: simple: Add support BOE nv101wxmn51

Resend the missing document. Sorry for the noise. 在 2016年12月08日 13:26, Caesar Wang 写道: > 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon > TFT's as an active switching devices. It can be supported by the > simple-panel driver. > > Signed-off-by: Caesar Wang

[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

Daniel, can we merge this patch? It has no dependency on other link train patches, it is just a clean up for the existing driver code that uses max link rate and lane count values. Other link train patches have dependency on this thats why it was part of the series. But it would be great if this

[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

On Thu, Dec 08, 2016 at 11:23:39PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > Sink's capabilities are advertised through DPCD registers and get > > updated only on hotplug. So they should be computed only once in the > > long pulse handler and saved off in intel_dp

[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs

only good solution is to rewrite the init parts, but I don't want to do that for a fix. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/6eaa6384/attachment.sig>

[PATCH] drm/panel: simple: Add support BOE nv101wxmn51

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon TFT's as an active switching devices. It can be supported by the simple-panel driver. Signed-off-by: Caesar Wang --- drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31

[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video

<https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ddef16be/attachment.html>

[Intel-gfx] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

Hi, On 07/12/2016 18:35, Robert Bragg wrote: > This is still missing corresponding documentation changes, and I haven't > moved anything to drm_print.h yet, as suggested. > > Sending out with a few functional improvements first to get agreement > before documenting anything (changes summarised

[RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: >> > Since the fbdev framework is in maintenance mode and all new display >> > drivers >> > should be made

[Bug 80419] XCOM: Enemy Unknown Causes lockup

in DPM or LLVM. DPM path is supported by this card being one of those needing a DPM quirk in si_dpm.c. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri

[PATCH] drm: Update drm_device docs about embedding.

On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote: > On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote: > > It's supported now! Spotted while reviewing Chris' patch to add a > > release hook. > > > > Cc: Chris Wilson > > Signed-off-by: Daniel Vetter > > --- > >

[PATCH] drm/mxsfb: fix pixel clock polarity

On 2016-12-07 18:37, Marek Vasut wrote: > On 12/08/2016 02:26 AM, Stefan Agner wrote: >> On 2016-12-07 16:59, Stefan Agner wrote: >>> On 2016-12-07 16:49, Marek Vasut wrote: On 12/08/2016 01:27 AM, Stefan Agner wrote: > The DRM subsystem specifies the pixel clock polarity from a >

[RFC] Using DC in amdgpu for upcoming GPU

On Thu, Dec 8, 2016 at 10:34 AM, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote: >> Hi Daniel, >> >> just a quick clarification in-line about "validation" inside atomic_commit. >> >> On 2016-12-08 04:59 AM, Daniel Vetter wrote: >> > Hi Harry, >> > >> > On

[PATCH] linux/types.h: enable endian checks for all sparse builds

On Thu, 8 Dec 2016 04:29:39 +0200 "Michael S. Tsirkin" wrote: > By now, linux is mostly endian-clean. Enabling endian-ness > checks for everyone produces about 200 new sparse warnings for me - > less than 10% over the 2000 sparse warnings already there. Out of curiousity: Where do most of those

[RFC] Using DC in amdgpu for upcoming GPU

putation code between check and commit doesn't get out of sync. > > > >> As for the rest, I hear you and appreciate your feedback. Let me get back > >> to > >> you on that later. > > Just an added note on that: I do think that there's some driver teams > > who've managed to pull a shared

[PATCH] linux/types.h: enable endian checks for all sparse builds

On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote: > On 12/07/16 21:54, Michael S. Tsirkin wrote: > > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote: > >> Additionally, there are notable exceptions to the rule that most drivers > >> are endian-clean, e.g.

[PATCH] drm: Update drm_device docs about embedding.

On Thu, Dec 08, 2016 at 12:53:07PM +0100, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote: > > On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote: > > > It's supported now! Spotted while reviewing Chris' patch to add a > > > release hook. > > > > > >

[PATCH 4/4] drm/vc4: Don't use drm_put_dev

vc4 already has a proper load sequence, but the unload one needed some fixups: First unregister, and last drop the final ref. Cc: Eric Anholt Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vc4/vc4_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH 3/4] drm/mediatek: don't use drm_put_dev

fsl is already fully demidlayered in the probe function, but for convenience stuck with drm_put_dev. Call the unregister/unref parts separately, to make sure this driver works correct. Cc: Philipp Zabel Cc: CK Hu Signed-off-by: Daniel Vetter --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++-

[PATCH 2/4] drm/fsl: don't use drm_put_dev

fsl is already fully demidlayered in the probe function, but for convenience stuck with drm_put_dev. Call the unregister/unref parts separately, to make sure this driver works correct. Cc: Stefan Agner Signed-off-by: Daniel Vetter --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++- 1 file

[PATCH 1/4] drm/etnaviv: Use drm_dev_unref, not drm_put_dev

drm_put_dev is the old midlayer-broken device cleanup function, but etnaviv has a proper unbind function which first unregisters and then drops the final reference. No functional change since drm_dev_unregister happens to be idempotent. Cc: Lucas Stach Cc: Russell King

[RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > Hi, > > Since the fbdev framework is in maintenance mode and all new display drivers > should be made with the DRM framework, remove the fbdev drivers from staging. > > Note: the patches are created with git format-patch -D, so they

  1   2   >