[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #35 from lei.p...@gmail.com --- (In reply to Michel Dänzer from comment #34) > (In reply to lei.pero from comment #33) > > Yeah, but by setting 1 and using any other WM results in Chromium/Chrome > > being VSYNC-ed, [...] > > With a

[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)

https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #18 from Michel Dänzer --- Please attach the current Xorg log file. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

Re: [PATCH] drm/amdgpu: shut up #warning for compile testing

On 02/02/17 12:59 AM, Arnd Bergmann wrote: > My randconfig tests on linux-next showed a newly introduced warning: > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function > 'amdgpu_bo_create_restricted': > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please > enable

[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)

https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #17 from Jean-François Fortin Tam --- I'm unfortunately still seeing this on an up-to-date Fedora 25 with kernel 4.9.6, DRM 2.48.0, LLVM 3.8.1, mesa 13.0.3, xorg-x11-drv-ati 7.7.1 (2016-09-28 git 3fc839ff) etc.

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #34 from Michel Dänzer --- (In reply to lei.pero from comment #33) > Yeah, but by setting 1 and using any other WM results in Chromium/Chrome > being VSYNC-ed, [...] With a compositing manager, tearing or not is

Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

Thanks for the review, Dhinakaran. Regards Shashank On 2/2/2017 1:23 AM, Pandiyan, Dhinakaran wrote: On Wed, 2017-02-01 at 18:14 +0530, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340Mhz. This patch adds few new functions in drm layer for

Re: [PATCH 5/6] drm/i915: enable scrambling

Regards Shashank On 2/1/2017 10:06 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote: Geminilake platform has a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks,

Re: [PATCH 4/6] drm: scrambling support in drm layer

Regards Shashank On 2/1/2017 10:02 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340Mhz. This patch adds few new functions in drm layer for core drivers to enable/disable

Re: [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

Thanks for the review Ville. My comments inline. Regards Shashank On 2/1/2017 10:03 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote: This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to

Re: [PATCH 4/6] drm: scrambling support in drm layer

Regards Shashank On 2/1/2017 10:02 PM, Thierry Reding wrote: On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340Mhz. This patch adds few new functions in drm layer for core drivers to enable/disable

Re: [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

Thanks for the review Thierry. My comments inline. Regards Shashank On 2/1/2017 9:40 PM, Thierry Reding wrote: On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote: This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used

[Bug 99637] VLC video has corrupted colors when using VDPAU output on Radeon SI

https://bugs.freedesktop.org/show_bug.cgi?id=99637 --- Comment #1 from Nayan Deshmukh --- The problem is already fixed in the master branch. This patch fixes the issue. Commit: 31908d6a4a3309f4cd4b953d6eecdf41595b1299 st/vdpau: only send buffers with B8G8R8A8

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #33 from lei.p...@gmail.com --- (In reply to Michel Dänzer from comment #32) > (In reply to lei.pero from comment #31) > > It's still odd behaviour, in both cases Chrome caps FPS to refresh rate > > (this > > case 85FPS), > > Sounds

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #32 from Michel Dänzer --- (In reply to lei.pero from comment #31) > It's still odd behaviour, in both cases Chrome caps FPS to refresh rate (this > case 85FPS), Sounds like Chrome just has its own framerate

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #31 from lei.p...@gmail.com --- (In reply to Michel Dänzer from comment #30) > (In reply to lei.pero from comment #29) > > Just want to add few things, did reported bug to gnome project, but, problem > > does not happen when

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #30 from Michel Dänzer --- (In reply to lei.pero from comment #29) > Just want to add few things, did reported bug to gnome project, but, problem > does not happen when "vblank_mode" value in .drirc configuration

[Bug 99637] VLC video has corrupted colors when using VDPAU output on Radeon SI

https://bugs.freedesktop.org/show_bug.cgi?id=99637 Matt Whitlock changed: What|Removed |Added Hardware|Other |x86-64

[Bug 99637] VLC video has corrupted colors when using VDPAU output on Radeon SI

https://bugs.freedesktop.org/show_bug.cgi?id=99637 Bug ID: 99637 Summary: VLC video has corrupted colors when using VDPAU output on Radeon SI Product: Mesa Version: 17.0 Hardware: Other OS: All

Re: [PATCH] drm: Don't race connector registration

On 02/01/2017 12:52 AM, Daniel Vetter wrote: > On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote: >> I added some printk()s all over and gathered a bit more information >> about what's going on. It looks like the display doesn't work until the >> drm connector code cleans up the *old*

Re: [PATCH 1/4] Documentation/devicetree/bindings/video/bridge: megachips-stdpxxxx-ge-b850v3-fw

On Sat, Jan 28, 2017 at 03:21:30PM +0100, Peter Senna Tschudin wrote: > Devicetree binding documentation for the second video output > of the GE B850v3: >STDP4028-ge-b850v3-fw bridges (LVDS-DP) >STDP2690-ge-b850v3-fw bridges (DP-DP++) > > Added entry for MegaChips at: >

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

On 01 February, 2017 12:35 CET, Daniel Vetter wrote: > On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote: > > Hi Archit, > > > > On 01 February, 2017 10:44 CET, Archit Taneja > > wrote: > > > > > > > > > > > On 01/30/2017 10:35

[PATCH] drm: mxsfb: Implement drm_panel handling

Currently when the 'power-supply' regulator is passed via device tree it does not actually work since drm_panel_prepare()/drm_panel_enable() are never called. Quoting Thierry Reding: "It should really call drm_panel_prepare() and drm_panel_enable() while switching on the display pipeline and

Re: [PATCH] drm: mxsfb: Implement drm_panel handling

Tested-by: Breno Lima From: Thierry Reding Sent: Wednesday, February 1, 2017 3:22 PM To: Fabio Estevam Cc: airl...@linux.ie; ma...@denx.de; dri-devel@lists.freedesktop.org; Breno Matheus Lima Subject: Re: [PATCH]

[PATCH] drm: vc4: adapt to new behaviour of drm_crtc.c

When drm_crtc_init_with_planes() was orignally added (in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary" being non-null. If that was the case, it modified primary->possible_crtcs. Then, when support for cursor planes

Re: [PATCH v1 2/2] drm/radeon: make MacBook Pro d3_delay quirk more generic

On Wed, Feb 01, 2017 at 04:45:42PM +0100, Andreas Boll wrote: > 2017-01-30 21:41 GMT+01:00 Bjorn Helgaas : > > The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond > > delay when powering on a device, i.e., transitioning from state D3hot to > > D0. > > > >

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On 01/31/2017 06:22 PM, Krzysztof Kozlowski wrote: On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae wrote: 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: Dear Thierry, Could you please review this patch? Thierry, I think this patch has been reviewed enough but no comment from

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

On Wed, Feb 1, 2017 at 9:46 AM, Hoegeun Kwon wrote: > The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected > using MIPI-DSI interfaces. > > Signed-off-by: Donghwa Lee > Signed-off-by: Hyungwon Hwang >

drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

Hi, I'm trying to use the Seiko 43WVF1G panel (Datasheet link: http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS driver on the i.MX6SX SabreSD. Applying the patch below removes the old timing configuration on the dtsi and adds it to the panel-simple.c I can get the display

Re: [PATCH 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

Hi, Some minor comments: On 01/28/2017 07:51 PM, Peter Senna Tschudin wrote: The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting

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

The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected using MIPI-DSI interfaces. Signed-off-by: Donghwa Lee Signed-off-by: Hyungwon Hwang Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda

[PATCH v9 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

From: Hyungwon Hwang This patch add the panel device tree node for S6E3HA2 display controller to TM2 dts. Signed-off-by: Hyungwon Hwang Signed-off-by: Andrzej Hajda Signed-off-by: Chanwoo Choi

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

Hi Archit, On 01 February, 2017 10:44 CET, Archit Taneja wrote: > > > On 01/30/2017 10:35 PM, Jani Nikula wrote: > > On Sat, 28 Jan 2017, Peter Senna Tschudin wrote: > >> On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote: > >>

Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

On Wed, 2017-02-01 at 18:14 +0530, Shashank Sharma wrote: > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > than 340Mhz. This patch adds few new functions in drm layer for > core drivers to enable/disable scrambling. > > This patch adds: > - A function to detect scrambling

[PATCH v9 0/3] Add support for the S6E3HA2 panel on TM2 board

Changes for V9: - Fixed the te-gpio to optional in bindings Changes for V8: - Applied below two patches: (drm/exynos) : drm/exynos: mic: Add mode_set callback function : drm/exynos: mic: Fix parse_dt function - The dt-binding patch and driver patch were divided. - Rebase these patches on

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote: > Hi Archit, > > On 01 February, 2017 10:44 CET, Archit Taneja wrote: > > > > > > > On 01/30/2017 10:35 PM, Jani Nikula wrote: > > > On Sat, 28 Jan 2017, Peter Senna Tschudin

[PATCH v9 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel driver. This panel has 1440x2560 resolution in 5.7-inch physical panel in the TM2 device. Signed-off-by: Donghwa Lee Signed-off-by: Hyungwon Hwang Signed-off-by: Hoegeun Kwon

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

On 01/30/2017 10:35 PM, Jani Nikula wrote: On Sat, 28 Jan 2017, Peter Senna Tschudin wrote: On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote: Hi Archit, Thank you for the comments! [...] + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) *

Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

On 02/01/2017 05:52 PM, Thierry Reding wrote: > On Wed, Feb 01, 2017 at 02:04:29PM -0200, Breno Matheus Lima wrote: >> Hi, >> >> I'm trying to use the Seiko 43WVF1G panel (Datasheet link: >> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS >> driver on >> the i.MX6SX SabreSD.

Re: [Freedreno] [PATCH 1/4] drm/msm: remove qcom, gpu-pwrlevels bindings

On Mon, Jan 30, 2017 at 01:35:47PM -0500, Rob Clark wrote: > On Mon, Jan 30, 2017 at 1:21 PM, Eric Anholt wrote: > > Rob Clark writes: > > > >> The plan is to use the OPP bindings. For now, remove the documentation > >> for qcom,gpu-pwrlevels, and make the

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #29 from lei.p...@gmail.com --- Just want to add few things, did reported bug to gnome project, but, problem does not happen when "vblank_mode" value in .drirc configuration file is set to 1 (instead of 0 I've used before). Thought

[Bug 193651] Amdgpu error messages at boot with Amd RX460

https://bugzilla.kernel.org/show_bug.cgi?id=193651 Alex Deucher changed: What|Removed |Added CC|

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

https://bugs.freedesktop.org/show_bug.cgi?id=99275 --- Comment #17 from Alex Deucher --- Does using the new ucode here help? https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/ -- You are receiving this mail because: You are the assignee for the

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

https://bugs.freedesktop.org/show_bug.cgi?id=99275 --- Comment #16 from Reimar Imhof --- I had an other look at 4.8. 4.8 is ok. Next try was 4.9-rc1. That one is buggy. Trying to bisect ended up in lots of unbootable kernels. git bisect start # good:

Re: [PATCH 2/2] drm: Rely on mode_config data for fb_helper initialization

Gabriel Krisman Bertazi writes: > Instead of receiving the num_crts as a parameter, we can read it > directly from the mode_config structure. I audited the drivers that > invoke this helper and I believe all of them (but one, see below) > initialize the mode_config

[Bug 99524] kernel hangs during shutdown (similar to Bug 98200)

https://bugs.freedesktop.org/show_bug.cgi?id=99524 wwa <10dma...@gmail.com> changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > Jani Nikula writes: > > > On Tue, 31 Jan 2017, Eric Anholt wrote: > >> Martin Peres writes: > >> > >>> Despite all the careful planing of the kernel, a

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

Jani Nikula writes: > On Tue, 31 Jan 2017, Eric Anholt wrote: >> Martin Peres writes: >> >>> Despite all the careful planing of the kernel, a link may become >>> insufficient to handle the currently-set mode. At this

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote: > Despite all the careful planing of the kernel, a link may become > insufficient to handle the currently-set mode. At this point, the > kernel should mark this particular configuration as being broken > and potentially prune the mode

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On Wed, Feb 01, 2017 at 03:29:40PM +, Emil Velikov wrote: > On 1 February 2017 at 14:52, Thierry Reding wrote: > > On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: > >> Thierry Reding writes: > >> > >> > [ Unknown signature

Re: [PATCH v4 3/6] drm/rockchip/dsi: dw-mipi: correct the coding style

On Tue, Jan 24, 2017 at 10:38:03AM +0800, Chris Zhong wrote: > correct the coding style, according the checkpatch scripts > Reviewed-by: Sean Paul > Signed-off-by: Chris Zhong > --- > > Changes in v4: None > Changes in v3: None > >

Re: [PATCH v4 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi

On Tue, Jan 24, 2017 at 10:38:02AM +0800, Chris Zhong wrote: > The vopb/vopl switch register of RK3399 mipi is different from RK3288, > the default setting for mipi dsi mode is different too, so add a > of_device_id structure to distinguish them, and make sure set the > correct mode before mipi

[PATCH 2/2] drm: Rely on mode_config data for fb_helper initialization

Instead of receiving the num_crts as a parameter, we can read it directly from the mode_config structure. I audited the drivers that invoke this helper and I believe all of them (but one, see below) initialize the mode_config struct accordingly, prior to calling the fb_helper. The auditing was

[PATCH 1/2] drm: sti: Prevent race on fbdev initialization

Scheduling the output_poll_work before calling bind_all to create the crtcs can race the fbdev initialization with the components initialization (i.e. crtc initialization). One side effect is that we may call drm_fbdev_cma_init with a zeroed num_crtc value, crashing the fbdev allocation. I found

Re: [PATCH v3 3/5] drm/rockchip/dsi: remove mode_valid function

On Tue, Jan 24, 2017 at 10:27:27AM +0800, Chris Zhong wrote: > Hi Sean > > On 01/24/2017 01:48 AM, Sean Paul wrote: > >On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote: > >>The MIPI DSI do not need check the validity of resolution, the max > >>resolution should depend VOP. Hence,

Re: [PATCH v3 6/7] dt-bindings: Add Multi-Inno MI0283QT binding

On Tue, Jan 31, 2017 at 05:03:18PM +0100, Noralf Trønnes wrote: > Add device-tree binding documentation for the MI0283QT display panel. > > Signed-off-by: Noralf Trønnes > --- > > Datasheet: https://cdn-shop.adafruit.com/datasheets/MI0283QT-11+V1.1.PDF > >

Re: [PATCH v3 5/7] dt-bindings: display: Add common rotation property

On Tue, Jan 31, 2017 at 05:03:17PM +0100, Noralf Trønnes wrote: > Display panels can be oriented many ways, especially in the embedded > world. The rotation property is a way to describe this orientation. > The counter clockwise direction is chosen because that's what fbdev > and drm use. The h/w

Re: [PATCH 2/4] drm/msm: drop qcom,chipid

On Wed, Feb 1, 2017 at 12:09 PM, Rob Herring wrote: > On Mon, Jan 30, 2017 at 11:49:19AM -0500, Rob Clark wrote: >> The original way we determined the gpu version was based on downstream >> bindings from android kernel. A cleaner way is to get the version from >> the compatible

Re: [PATCH v4 1/3] drm/atomic: Save flip flags in drm_crtct_state

On Wed, Feb 01, 2017 at 12:03:34PM -0500, Andrey Grodzovsky wrote: > Allows using atomic flip helpers for drivers > using ASYNC flip. > Remove ASYNC_FLIP restriction in helpers and > caches the page flip flags in drm_crtc_state > to be used in the low level drivers. > > v2: > Resending the patch

Re: [PATCH v3 13/24] drm/rockchip: dw-mipi-dsi: fix escape clock rate

On Mon, 30 Jan 2017 15:25:10 -0500, Sean Paul wrote: > On Sun, Jan 29, 2017 at 01:24:33PM +, John Keeping wrote: > > This clock rate is derived from the PHY PLL, so it should be calculated > > dynamically. Use the same calculation as the vendor kernel to derive > > the escape clock speed. >

Re: [PATCH] drm: mxsfb: Implement drm_panel handling

On Wed, Feb 01, 2017 at 03:19:47PM -0200, Fabio Estevam wrote: > Currently when the 'power-supply' regulator is passed via device tree > it does not actually work since drm_panel_prepare()/drm_panel_enable() > are never called. > > Quoting Thierry Reding: "It should really call

[PATCH v4 3/3] drm/amd/display: Switch to using atomic_helper for flip.

v2: Modify for movig pflip flags to crtc_state v4: Fix identation. Change-Id: I25dae6d8c29de5d022a42aa99a18a32674b56cda Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c

Re: [PATCH v2] drm: Clean up the 1366x768 fixup codes

On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote: > On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote: > > This is just a cleanup, no functional change. > > > > The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is > > basically a copy of the existing code

Re: [PATCH 4/4] drm/msm: drop _clk suffix from clk names

On Mon, Jan 30, 2017 at 11:49:21AM -0500, Rob Clark wrote: > Suggested by Rob Herring. We still support the old names for > compatibility with downstream android dt files. > > Cc: Rob Herring > Signed-off-by: Rob Clark > --- >

Re: [PATCH 2/4] drm/msm: drop qcom,chipid

On Mon, Jan 30, 2017 at 11:49:19AM -0500, Rob Clark wrote: > The original way we determined the gpu version was based on downstream > bindings from android kernel. A cleaner way is to get the version from > the compatible string. > > Note that no upstream dtb uses these bindings. But the code

[PATCH v4 1/3] drm/atomic: Save flip flags in drm_crtct_state

Allows using atomic flip helpers for drivers using ASYNC flip. Remove ASYNC_FLIP restriction in helpers and caches the page flip flags in drm_crtc_state to be used in the low level drivers. v2: Resending the patch since the original was broken. v3: Save flag in crtc_state instead of plane_state

[PATCH v4 0/3] Allow ASYNC flip with atomic helpers.

This series is a folow-up on https://patchwork.kernel.org/patch/9501787/ The first patch makes changes to atomic helpers to allow for drives with ASYNC flip support to use them. Patch 2 is to use this in AMDGPU/DC. Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the

[PATCH v4 2/3] drm/nouveau/kms/nv50: Switch to using atomic helper for flip.

v2: Update code after flip_flags moved from plane_state to crtc_state Change-Id: I5a3189c03e389af2ff6c13d870a7d28282b7b0ee Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/nouveau/nv50_display.c | 84 -- 1 file changed, 10

Re: [PATCH 1/4] drm/msm: remove qcom,gpu-pwrlevels bindings

On Mon, Jan 30, 2017 at 11:49:18AM -0500, Rob Clark wrote: > The plan is to use the OPP bindings. For now, remove the documentation > for qcom,gpu-pwrlevels, and make the driver fall back to a safe low > clock if the node is not present. > > Note that no upstream dtb use this node. For now we

Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

On Wed, Feb 01, 2017 at 02:48:55PM -0200, Fabio Estevam wrote: > On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima > wrote: > > Hi, > > > > I'm trying to use the Seiko 43WVF1G panel (Datasheet link: > > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS

Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

On Wed, Feb 01, 2017 at 02:04:29PM -0200, Breno Matheus Lima wrote: > Hi, > > I'm trying to use the Seiko 43WVF1G panel (Datasheet link: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS > driver on > the i.MX6SX SabreSD. Applying the patch below removes the old > timing

Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima wrote: > Hi, > > I'm trying to use the Seiko 43WVF1G panel (Datasheet link: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS driver > on > the i.MX6SX SabreSD. Applying the patch below removes the

[Bug 69897] OpenCL kernel fails to compile with R600 LLVM backend

https://bugs.freedesktop.org/show_bug.cgi?id=69897 Jan Vesely changed: What|Removed |Added Attachment #86758|text/plain

[Bug 69897] OpenCL kernel fails to compile with R600 LLVM backend

https://bugs.freedesktop.org/show_bug.cgi?id=69897 --- Comment #7 from Vedran Miletić --- Grigori, can you repost the kernel? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

Re: [PATCH 5/6] drm/i915: enable scrambling

On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote: > Geminilake platform has a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the

Re: [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote: > This patch does following: > - Adds a new structure (drm_hdmi_info) in drm_display_info. > This structure will be used to save and indicate if sink > supports advance HDMI 2.0 features > - Checks the HF-VSDB block for presence

Re: [PATCH 4/6] drm: scrambling support in drm layer

On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > than 340Mhz. This patch adds few new functions in drm layer for > core drivers to enable/disable scrambling. > > This patch adds: > - A function to detect

[Bug 95306] Random Blank(black) screens on "Carrizo"

https://bugs.freedesktop.org/show_bug.cgi?id=95306 --- Comment #55 from Jaime Rodrigo --- I kind of have the same laptop, manufactured for a different region. I can confirm it doesn't work well with 4.10 RC6 (for me it blanks before the login screen). 4.10 RC5 works great,

[Bug 99628] AMD Radeon HD 8600M graphics card doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 Alex Deucher changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop

Re: [PATCH 4/6] drm: scrambling support in drm layer

On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > than 340Mhz. This patch adds few new functions in drm layer for > core drivers to enable/disable scrambling. > > This patch adds: > - A function to detect

Re: [PATCH v2 0/2] drm amdgpu/radeon: clean up d3_delay usage

For the series: Reviewed-by: Andreas Boll 2017-02-01 17:22 GMT+01:00 Bjorn Helgaas : > amdgpu doesn't need to touch pdev->d3_delay at all. > > radeon has a d3_delay quirk for MacBook Pro, but it only affects > radeon_switcheroo_set_state(). I

[Bug 99628] AMD Radeon HD 8600M graphics card doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 --- Comment #4 from mohsen2120habibik...@gmail.com --- Created attachment 129274 --> https://bugs.freedesktop.org/attachment.cgi?id=129274=edit The result of cat ~/.local/share/xorg/Xorg.0.log -- You are receiving this mail because: You are

[PATCH v2 2/2] drm/radeon: make MacBook Pro d3_delay quirk more generic

The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond delay when powering on a device, i.e., transitioning from state D3hot to D0. Apparently some devices require more time, and d1f9809ed131 ("drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks")

[PATCH v2 0/2] drm amdgpu/radeon: clean up d3_delay usage

amdgpu doesn't need to touch pdev->d3_delay at all. radeon has a d3_delay quirk for MacBook Pro, but it only affects radeon_switcheroo_set_state(). I think it should affect wakeups done by the PCI core as well. Changes from v1 to v2: - Fix accidental removal of "{ 0, 0, 0, 0, 0 }" quirk list

[PATCH v2 1/2] drm/amdgpu: remove unnecessary save/restore of pdev->d3_delay

Remove unnecessary save/restore of pdev->d3_delay. The only assignments to pdev->d3_delay are in radeon_switcheroo_set_state() and some quirks, none of which should be relevant in the amdgpu_switcheroo_set_state() path. Signed-off-by: Bjorn Helgaas Acked-by: Alex Deucher

Re: [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote: > This patch does following: > - Adds a new structure (drm_hdmi_info) in drm_display_info. > This structure will be used to save and indicate if sink > supports advance HDMI 2.0 features "advanced" > - Checks the HF-VSDB block

[Bug 99628] AMD Radeon HD 8600M graphics card doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 --- Comment #3 from Alex Deucher --- The driver appears to be loaded fine. What exactly are you trying to do? The dGPU has no displays attached so you have to use the integrated GPU for display. You can select the dGPU

[Bug 99628] AMD Radeon HD 8600M graphics card doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 --- Comment #2 from mohsen2120habibik...@gmail.com --- Created attachment 129273 --> https://bugs.freedesktop.org/attachment.cgi?id=129273=edit dmesg result No, it didn't help. dmesg result -- You are receiving this mail because: You are the

[PATCH] drm/amdgpu: shut up #warning for compile testing

My randconfig tests on linux-next showed a newly introduced warning: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function 'amdgpu_bo_create_restricted': drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance

Re: [PATCH libdrm 2/3] tests/util: Make util_open() use drmDevice

On Wed, Feb 01, 2017 at 12:47:21PM +, Emil Velikov wrote: > On 30 January 2017 at 10:29, Thierry Reding wrote: > > From: Thierry Reding > > > > The util_open() helper is used in a couple of test programs to open an > > appropriate device. It

[Bug 99628] AMD Radeon HD 8600M graphics card doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 Alex Deucher changed: What|Removed |Added Priority|highest |medium ---

Re: [PATCH v1 2/2] drm/radeon: make MacBook Pro d3_delay quirk more generic

2017-01-30 21:41 GMT+01:00 Bjorn Helgaas : > The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond > delay when powering on a device, i.e., transitioning from state D3hot to > D0. > > Apparently some devices require more time, and d1f9809ed131 ("drm/radeon:

Re: [PATCH libdrm] Remove unused tests/drmstat.c

Reviewed-by: Andreas Boll 2017-02-01 16:32 GMT+01:00 Emil Velikov : > From: Emil Velikov > > Earlier commit removed all the legacy 'tests' but a file was left > danglig. > > Cc: Andreas Boll

[Bug 99628] AMD Radeon HD 8600M graphics doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 mohsen2120habibik...@gmail.com changed: What|Removed |Added Priority|medium |highest -- You are

[Bug 99628] AMD Radeon HD 8600M graphics card doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 mohsen2120habibik...@gmail.com changed: What|Removed |Added Summary|AMD Radeon HD 8600M |AMD Radeon HD 8600M

[Bug 99628] AMD Radeon HD 8600M graphics doesn't work with amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99628 Bug ID: 99628 Summary: AMD Radeon HD 8600M graphics doesn't work with amdgpu Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

[PATCH libdrm] Remove unused tests/drmstat.c

From: Emil Velikov Earlier commit removed all the legacy 'tests' but a file was left danglig. Cc: Andreas Boll Reported-by: Andreas Boll Fixes: 0c80fddd1d0 "tests: remove useless legacy tests" Signed-off-by:

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On 1 February 2017 at 14:52, Thierry Reding wrote: > On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: >> Thierry Reding writes: >> >> > [ Unknown signature status ] >> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:

[Bug 97556] amdgpu fan behavior doesn't match windows

https://bugs.freedesktop.org/show_bug.cgi?id=97556 --- Comment #5 from Sergey Kochneff --- In addition to my previous comment. pwm1_enable always reads “1” which usually means “manual control”, and writing “2” (hardware control) or higher values doesn’t change file contents

[Bug 97556] amdgpu fan behavior doesn't match windows

https://bugs.freedesktop.org/show_bug.cgi?id=97556 --- Comment #4 from Sergey Kochneff --- On ASUS Strix RX 470, “fan stop” works fine on firmware boot and in GRUB, but after loading amdgpu module fan starts to spin and never stops. Although it’s possible to emulate proper

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: > Thierry Reding writes: > > > [ Unknown signature status ] > > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: > >> Thierry Reding writes: > >> > >> > [ Unknown

  1   2   >