[git pull] drm fixes for v4.10-rc3.

Hi Linus, Bunch of fixes across the drivers, in a St Patrick's day pull request. (please turn terminal colors to green on black or black on green for full effect). On the arm side, tilcdc, omap and malidp got fixes, while amd has some powermanagement fixes, and intel has a set of fixes across

Re: [RFC libdrm 0/2] Replace the build system with meson

Quoting Marek Olšák (2017-03-16 18:53:59) > On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker wrote: > > Quoting Marek Olšák (2017-03-16 15:36:26) > >> Is there a way not to use ninja with meson, because ninja redirects > >> all stderr output from gcc to stdout, which breaks many

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

quoting jason ekstrand (2017-03-16 19:03:15) > on march 16, 2017 5:41:24 pm emil velikov wrote: > > and meson is not a thing on neither bsd(s), solaris (and derivatives) nor > > android :-\ > > i have trouble bringing myself to care. the bsds need to stop using 10 >

[PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

For RK3399, the grf clk should be enabled before writing grf registers, otherwise the register value can not be changed. Signed-off-by: Chris Zhong --- Changes in v3: - add a DW_MIPI_NEEDS_GRF_CLK for RK3399 Changes in v2: - check the grf_clk only for RK3399

[PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Signed-off-by: Chris Zhong --- Changes in v3: None Changes in v2: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 +- 1 file changed,

[PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is disabled, MIPI phy can not work. Let's return a error if there is no phy_cfg_clk in dts property, when the pdata match RK3399. Signed-off-by: Chris Zhong --- Changes in v3: - add a DW_MIPI_NEEDS_PHY_CFG_CLK

[PATCH v3 0/4] RK3399 dw-mipi-dsi patches

Hi all This series set the phy_cfg_clk to be a required clock for RK3399, and add a grf clock control in dw-mipi-dsi driver. And then correct a register name. Changes in v3: - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399 - add a DW_MIPI_NEEDS_GRF_CLK for RK3399 Changes in v2: - check the grf_clk

[PATCH v3 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20, not RK3399_GRF_SOC_CON19. Signed-off-by: Chris Zhong --- Changes in v3: None Changes in v2: None drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH] drm/msm/mdp5: Update SSPP_MAX value

'SSPP_MAX + 1' is the max number of hwpipes that can be present on a MDP5 platform. Recently, 2 new cursor hwpipes were added, which caused overflows in arrays that used SSPP_MAX to represent the number of elements. Update the SSPP_MAX value to incorporate the extra hwpipes. Signed-off-by: Archit

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

https://bugs.freedesktop.org/show_bug.cgi?id=64776 Timothy Arceri changed: What|Removed |Added Resolution|--- |INVALID

Re: [RFC libdrm 0/2] Replace the build system with meson

On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker wrote: > Quoting Marek Olšák (2017-03-16 15:36:26) >> Is there a way not to use ninja with meson, because ninja redirects >> all stderr output from gcc to stdout, which breaks many development >> environments that expect errors in

Re: [PATCH v2 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

Hi John On 03/16/2017 06:55 PM, John Keeping wrote: On Thu, 16 Mar 2017 11:31:44 +0800, Chris Zhong wrote: For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is disabled, MIPI phy can not work. Let's return a error if there is no phy_cfg_clk in dts property, when the pdata match

[PATCH v2 2/8] clk: sunxi-ng: add support for DE2 CCU

The "Display Engine 2.0" in Allwinner newer SoCs contains a clock management unit for its subunits, like the DE CCU in A80. Add a sunxi-ng style driver for it. Signed-off-by: Icenowy Zheng --- Changes in v2: - Rename sunxi-de2-ccu to sun8i-de2-ccu.

[PATCH v2 0/8] Initial Allwinner Display Engine 2.0 Support

This patchset is the initial patchset for Allwinner DE2 support. It contains the support of clocks in DE2 and the mixers in DE2. The SoC used to develop this patchset is V3s, as V3s is the simplest one of the SoCs that have DE2. (Allwinner V3s features only one mixer, although its clock control

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

On Wed, Mar 15, 2017 at 03:19:12PM +0800, Chris Zhong wrote: > The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and > connected to DSI using four lanes. > > Signed-off-by: Chris Zhong > --- > > Changes in v2: None You added documentation for the 'reg'

Re: [PATCH v2 0/4] RK3399 dw-mipi-dsi patches

On Thu, Mar 16, 2017 at 11:31:43AM +0800, Chris Zhong wrote: > Hi all > > This series set the phy_cfg_clk to be a required clock for RK3399, and > add a grf clock control in dw-mipi-dsi driver. And then correct a > register name. > > > Changes in v2: > - check the grf_clk only for RK3399 For

[PATCH v2 8/8] ARM: dts: sun8i: enable LCD panel of Lichee Pi Zero

A 480x272 QiaoDian QD43003C0-40-7LED panel is available from Lichee Pi. This commit connects this panel to Lichee Pi Zero. Lichee Pi also provides a 800x480 panel without accurate model number, so do not merge this patch. It will finally come as device tree overlay. Signed-off-by: Icenowy Zheng

[PATCH v2 4/8] drm/sun4i: add support for sun8i DE2 mixers and display engines

Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes in a new "Display Engine" (mixers instead of old backends and frontends). Add support for the mixer on Allwinner V3s SoC; it's the simplest one. Currently a lot of functions are still missing -- more investigations are

[PATCH v2 7/8] ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC

Allwinner V3s SoC features a set of pins that have functionality of RGB LCD, the pins are at different pin ban than other SoCs. Add pinctrl node for them. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v3s.dtsi | 9 + 1 file changed, 9 insertions(+) diff

Re: [PATCH v4] drm/rockchip: Refactor the component match logic.

Hi Heiko, On 03/16/2017 04:20 PM, Heiko Stuebner wrote: Hi Jeffy, Am Donnerstag, 16. März 2017, 10:05:56 CET schrieb Jeffy Chen: Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match

[PATCH v2 1/8] dt-bindings: add binding for the Allwinner DE2 CCU

Allwinner "Display Engine 2.0" contains some clock controls in it. Add them as a clock driver, and make a device tree binding. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/clock/sun8i-de2.txt| 31 ++ 1 file changed, 31 insertions(+)

[PATCH v2 5/8] drm/sun4i: tcon: add support for V3s TCON

Allwinner V3s SoC features a TCON without channel 1. Add support for it. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++- drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 + 2 files changed, 7 insertions(+), 1 deletion(-) diff --git

[PATCH v2 3/8] dt-bindings: add bindings for DE2 on V3s SoC

Allwinner V3s SoC have a display engine which have a different pipeline with older SoCs. Add document for it (new compatibles and the new "mixer" part). The paragraph of TCON is also refactored, for furtherly add TCONs in A83T/H3/A64/H5 that have only a channel 1 (used for HDMI or TV Encoder).

[PATCH v2 6/8] ARM: dts: sun8i: add DE2 nodes for V3s SoC

Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON which have RGB LCD output. Add device nodes for it as well as the TCON. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v3s.dtsi | 87 1 file changed, 87

Re: [PATCH V4] dts/imx6q-b850v3: Use megachips-stdpxxxx-ge-b850v3-fw bridges (LVDS-DP++)

On Thu, Mar 16, 2017 at 09:41:03AM +0100, Daniel Vetter wrote: > On Thu, Mar 16, 2017 at 10:34:59AM +0800, Shawn Guo wrote: > > I fixed up all of them and applied patch. > > +1 on doing review like this. And for committers you can do "with all that > fixed r-b: me" and let them fix it up & push

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote: > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI > panel. > > Signed-off-by: Chris Zhong > --- > > Changes in v2: > - add some error check > - always use Low power mode to send commend > -

[PATCH v5 7/8] drm: Connector helper function to release resources

From: "Pandiyan, Dhinakaran" Having an ->atomic_release callback is useful to release shared resources that get allocated in compute_config(). This function is expected to be called in the atomic_check() phase before new resources are acquired. v4: Document that

Re: [RFC libdrm 0/2] Replace the build system with meson

On 17 March 2017 at 00:21, Dylan Baker wrote: > Hi Emil, > > Quoting Emil Velikov (2017-03-16 16:35:33) >> While I can see you're impressed by Meson, I would kindly urge you to >> not use it here. As you look closely you can see that one could >> trivially improve the times,

Re: [RFC libdrm 0/2] Replace the build system with meson

Hi Emil, Quoting Emil Velikov (2017-03-16 16:35:33) > While I can see you're impressed by Meson, I would kindly urge you to > not use it here. As you look closely you can see that one could > trivially improve the times, yet the biggest thing is that most of the > code in libdrm must go ;-)

[PATCH 2/2] drm: Peek at the current counter/timestamp for vblank queries

Bypass all the spinlocks and return the last timestamp and counter from the last vblank if the driver delcares that it is accurate (and stable across on/off), and the vblank is currently enabled. This is dependent upon the both the hardware and driver to provide the proper barriers to facilitate

[PATCH 1/2] drm: Mark up accesses of vblank->enabled outside of its spinlock

Order the update to vblank->enabled after the timestamp is primed so that a concurrent unlocked reader will only see the vblank->enabled with the current timestamp. Signed-off-by: Chris Wilson Cc: Ville Syrjälä Cc: Daniel Vetter

Re: [RFC libdrm 0/2] Replace the build system with meson

Hi Dylan, On 16 March 2017 at 21:25, Dylan Baker wrote: > Why bother, and why would we want this? >│~ > > First it's written in python, which means the potential developer base > is massive. And it provides a

Re: [RFC libdrm 0/2] Replace the build system with meson

Quoting Marek Olšák (2017-03-16 15:36:26) > Is there a way not to use ninja with meson, because ninja redirects > all stderr output from gcc to stdout, which breaks many development > environments that expect errors in stderr? > > I'm basically saying that if ninja can't keep gcc errors in

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

https://bugs.freedesktop.org/show_bug.cgi?id=100242 --- Comment #2 from tnmailingli...@gmail.com --- Created attachment 130279 --> https://bugs.freedesktop.org/attachment.cgi?id=130279=edit gdb bt -- You are receiving this mail because: You are the assignee for the

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

https://bugs.freedesktop.org/show_bug.cgi?id=100242 --- Comment #1 from tnmailingli...@gmail.com --- Created attachment 130278 --> https://bugs.freedesktop.org/attachment.cgi?id=130278=edit strace -- You are receiving this mail because: You are the assignee for the

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

https://bugs.freedesktop.org/show_bug.cgi?id=100242 Bug ID: 100242 Summary: radeon buffer allocation failure during startup of Factorio Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All)

Re: [RFC libdrm 0/2] Replace the build system with meson

Is there a way not to use ninja with meson, because ninja redirects all stderr output from gcc to stdout, which breaks many development environments that expect errors in stderr? I'm basically saying that if ninja can't keep gcc errors in stderr, I wouldn't like any project that I might be

[RFC PATCH 0/3] drm/panel: Pull some code out into common helpers

This series pulls out the power-sequencing code from panel-simple into a panel-common helper library. This allows drivers that cannot leverage panel-simple to share some code. I've converted the 2 sharp mipi drivers, and Chris Zhong's driver on the list can also be converted. I haven't checked

[RFC PATCH 3/3] drm/panel: panel-sharp-ls043t1le01: Use panel-common helpers

Instead of duplicating common code from panel-simple, use the panel-common helpers. Signed-off-by: Sean Paul --- drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 70 +++-- 2 files changed, 20

[RFC PATCH 2/3] drm/panel: sharp-lq101r1sx01: Use panel-common helpers

Instead of duplicating common code from panel-simple, use the panel-common helpers. Signed-off-by: Sean Paul --- drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 79 +++-- 2 files changed, 24

[RFC PATCH 1/3] drm/panel: Pull common panel code out into helpers

This patch pulls the regulator/backlight/enable_gpio code out of panel-simple and creates a new panel-common helper with it. This helper will be useful to the more complicated drivers which cannot use panel-simple. Signed-off-by: Sean Paul ---

Re: [RFC libdrm 0/2] Replace the build system with meson

Quoting Ilia Mirkin (2017-03-16 14:32:09) > On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote: > > Why bother, and why would we want this? > > │~ > > > > First it's written in python, which means the potential

Re: [RFC libdrm 0/2] Replace the build system with meson

On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote: > Why bother, and why would we want this? >│~ > > First it's written in python, which means the potential developer base > is massive. And it provides a

[RFC libdrm 1/2] Port build system to meson

This is a bit of a tech demo, a bit of a serious port to meson. This provides almost all of the build system, except for the ability to install the tests, it doesn't add -lrt for the clock (it's been in core glibc for some time), has basically no comments, and hasn't been tested on any platform

[RFC libdrm 2/2] remove autotools build

This is mostly to demonstrate all of the code that would be deleted by removing the autotools build. This is *not* ready to land, since it deletes some files used by the android build (Makefile.sources). --- .editorconfig| 4 +- .gitignore | 82 +-

[RFC libdrm 0/2] Replace the build system with meson

Why bother, and why would we want this? ???~ First it's written in python, which means the potential developer base is massive. And it provides a recursive view for humans, but a non-recursive view for the system. This is the best of

[Bug 100239] Incorrect rendering in CS:GO

https://bugs.freedesktop.org/show_bug.cgi?id=100239 --- Comment #1 from Samuel Pitoiset --- Thanks for reporting this. It would be nice if you can upload good/bad screenshots. And it would be very nice if you can record an apitrace which reproduces the issue. -- You

Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

Hi Rob, On Thu, Mar 16, 2017 at 9:56 PM, Rob Herring wrote: > On Thu, Mar 16, 2017 at 09:13:16AM +0100, Geert Uytterhoeven wrote: >> On Wed, Mar 15, 2017 at 6:01 PM, Rob Herring wrote: >> > On Mon, Mar 06, 2017 at 05:25:56PM +0100, Geert Uytterhoeven wrote: >>

Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

On Thu, Mar 16, 2017 at 09:13:16AM +0100, Geert Uytterhoeven wrote: > Hi Rob, > > On Wed, Mar 15, 2017 at 6:01 PM, Rob Herring wrote: > > On Mon, Mar 06, 2017 at 05:25:56PM +0100, Geert Uytterhoeven wrote: > >> Document the optional properties for describing module resets, to >

[Bug 100239] Incorrect rendering in CS:GO

https://bugs.freedesktop.org/show_bug.cgi?id=100239 Bug ID: 100239 Summary: Incorrect rendering in CS:GO Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority:

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst wrote: > Op 16-03-17 om 16:52 schreef Daniel Vetter: >> The vblank code really wants to look at crtc->state without having to >> take a ww_mutex. One option might be to take one of the vblank locks >> right when

Re: [PATCH libdrm 1/2] xf86drm: add missing include

On 16 March 2017 at 17:00, Eric Engestrom wrote: > On Thursday, 2017-03-16 15:09:15 +, Emil Velikov wrote: >> On 16 March 2017 at 13:56, Eric Engestrom wrote: >> > GCC 7 complains about major(), minor() and makedev(): >> > warning: In

[PATCH] drm: vc4: remove redundant check of plane being non-null

From: Colin Ian King The pointer plane is always null on the error path at label 'fail' hence the check if it is non-null is redundant. We can therefore remove the check and the destruction of plane as well as the fail error path and instead just return an -ENOMEM

Re: [PATCH v2 2/3] drm/vc4: Add HDMI audio support

Eric Anholt writes: > The HDMI encoder IP embeds all needed blocks to output audio, with a > custom DAI called MAI moving audio between the two parts of the HDMI > core. This driver now exposes a sound card to let users stream audio > to their display. > > Using the hdmi-codec

Re: DRM Atomic property for color-space conversion

On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/16/2017 5:55 PM, Brian Starkey wrote: > > Hi, > > > > On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 3/16/2017 4:37 PM, Local

[Bug 100222] Hang regression with R7 M370, identified possible culprit commit

https://bugs.freedesktop.org/show_bug.cgi?id=100222 --- Comment #5 from Mauro Santos --- (In reply to Alex Deucher from comment #4) > The patch modifies si_apply_state_adjust_rules, I guess it's not applying > cleanly to your kernel. I've retried it with the current

Re: [PATCH v3 2/6] media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller

On 3/7/2017 10:12 PM, Neil Armstrong wrote: In order to describe the RGB and YUB bus formats used to feed the s/YUB/YUV Synopsys DesignWare HDMI TX Controller, add missing formats to the list of Bus Formats. Documentation for these formats is added in a separate patch. Reviewed-by:

Re: DRM Atomic property for color-space conversion

Regards Shashank On 3/16/2017 5:55 PM, Brian Starkey wrote: Hi, On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank wrote: Regards Shashank On 3/16/2017 4:37 PM, Local user for Liviu Dudau wrote: On Thu, Mar 16, 2017 at 04:30:59PM +0200, Ville Syrjälä wrote: On Thu, Mar 16, 2017

Re: [PATCH v3 3/6] documentation: media: Add documentation for new RGB and YUV bus formats

On 3/7/2017 10:12 PM, Neil Armstrong wrote: Add documentation for added Bus Formats to describe RGB and YUS formats used s/YUS/YUV as input to the Synopsys DesignWare HDMI TX Controller. Signed-off-by: Neil Armstrong ---

Re: [PATCH libdrm 1/2] xf86drm: add missing include

On Thursday, 2017-03-16 15:09:15 +, Emil Velikov wrote: > On 16 March 2017 at 13:56, Eric Engestrom wrote: > > GCC 7 complains about major(), minor() and makedev(): > > warning: In the GNU C Library, "major" is defined by . > > For historical compatibility,

Re: [PATCH libdrm] atomic: fix atomic_add_unless() fallback's return value

On Thursday, 2017-03-16 00:08:59 +, Eric Engestrom wrote: > According to the kernel documentation: > Returns non-zero if @v was not @u, and zero otherwise. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100077 > Fixes: 63fc571863aa64683400 ("atomic: add atomic_add_unless()") >

Re: [PATCH 00/41] Chromebook Plus (aka kevin) kernel patches

2017-03-14 21:43 GMT+01:00 Sean Paul : > On Thu, Mar 09, 2017 at 11:32:15PM -0500, Sean Paul wrote: >> Despite our best intentions (and we did a decent job this time around) of >> submitting >> upstream first for the Chromebook Plus, we had a number of patches slip >>

Re: [PATCH v3 5/6] drm: bridge: dw-hdmi: Add Documentation on supported input formats

On 3/7/2017 10:12 PM, Neil Armstrong wrote: This patch adds a new DRM documentation entry and links to the input format table added in the dw_hdmi header. Signed-off-by: Neil Armstrong --- Documentation/gpu/dw-hdmi.rst | 15 +++

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

Op 16-03-17 om 16:52 schreef Daniel Vetter: > The vblank code really wants to look at crtc->state without having to > take a ww_mutex. One option might be to take one of the vblank locks > right when assigning crtc->state, which would ensure that the vblank > code doesn't race and access freed

Re: DRM Atomic property for color-space conversion

Hi, On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank wrote: Regards Shashank On 3/16/2017 4:37 PM, Local user for Liviu Dudau wrote: On Thu, Mar 16, 2017 at 04:30:59PM +0200, Ville Syrjälä wrote: On Thu, Mar 16, 2017 at 04:20:29PM +0200, Sharma, Shashank wrote: Regards Shashank

[PATCH] drm/atomic: protect crtc|connector->state with rcu

The vblank code really wants to look at crtc->state without having to take a ww_mutex. One option might be to take one of the vblank locks right when assigning crtc->state, which would ensure that the vblank code doesn't race and access freed memory. But userspace tends to poke the vblank_ioctl

[Bug 100089] [regression] [bisected] Space Run rendering issues

https://bugs.freedesktop.org/show_bug.cgi?id=100089 Samuel Pitoiset changed: What|Removed |Added Summary|Space Run rendering prolems

Re: DRM Atomic property for color-space conversion

Regards Shashank On 3/16/2017 4:37 PM, Local user for Liviu Dudau wrote: On Thu, Mar 16, 2017 at 04:30:59PM +0200, Ville Syrjälä wrote: On Thu, Mar 16, 2017 at 04:20:29PM +0200, Sharma, Shashank wrote: Regards Shashank On 3/16/2017 4:07 PM, Ville Syrjälä wrote: On Tue, Jan 31, 2017 at

Re: [PATCH libdrm 1/2] xf86drm: add missing include

On 16 March 2017 at 13:56, Eric Engestrom wrote: > GCC 7 complains about major(), minor() and makedev(): > warning: In the GNU C Library, "major" is defined by . > For historical compatibility, it is currently defined by as > well, but we plan to remove

Re: [PATCH 20/41] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy

On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang > > Following the correct power up sequence: > dp_pd=ff => dp_pd=7f => wait 10us => dp_pd=00 Please fix the message. > > Cc: Stéphane Marchesin > Signed-off-by: zain wang >

Re: [PATCH 19/41] drm/bridge: analogix_dp: Wait for HPD signal before configuring link

On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang > > According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker > must first detect that the HPD signal is asserted high by the Downstream > Device before establishing a link with it. > > Cc: Stéphane

Re: [PATCH 18/41] drm/bridge: analogix_dp: Retry bridge enable when it failed

On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang > > When we enable bridge failed, we have to retry it, otherwise we would get > the abnormal display. > > Cc: Stéphane Marchesin > Signed-off-by: zain wang > Signed-off-by:

Re: DRM Atomic property for color-space conversion

On Thu, Mar 16, 2017 at 04:30:59PM +0200, Ville Syrjälä wrote: > On Thu, Mar 16, 2017 at 04:20:29PM +0200, Sharma, Shashank wrote: > > Regards > > > > Shashank > > > > > > On 3/16/2017 4:07 PM, Ville Syrjälä wrote: > > > On Tue, Jan 31, 2017 at 03:55:41PM +, Brian Starkey wrote: > > >> On

Re: DRM Atomic property for color-space conversion

On Thu, Mar 16, 2017 at 04:20:29PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/16/2017 4:07 PM, Ville Syrjälä wrote: > > On Tue, Jan 31, 2017 at 03:55:41PM +, Brian Starkey wrote: > >> On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote: > >>> On Tue, Jan 31,

Re: [PATCH 17/41] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up

On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang > > Panel would reset it's setting when it power down. It would forget the last > successed link training setting. So we can't use the last successful link > training setting to do fast link training. Let's reset

Re: [PATCH 16/41] drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer

On 10.03.2017 05:32, Sean Paul wrote: > From: Lin Huang > > We should check AUX_EN bit to confirm the AUX CH operation is completed. > > Cc: Stéphane Marchesin > Signed-off-by: Lin Huang > Signed-off-by: zain wang

Re: [PATCH 15/41] drm/bridge: analogix_dp: Move enable video into config_video()

On 10.03.2017 05:32, Sean Paul wrote: > From: Lin Huang > > We need to enable video before analogix_dp_is_video_stream_on(), so > we can get the right video stream status. > > Cc: 征增 王 > Cc: Stéphane Marchesin > Signed-off-by: Lin

Re: DRM Atomic property for color-space conversion

Regards Shashank On 3/16/2017 4:07 PM, Ville Syrjälä wrote: On Tue, Jan 31, 2017 at 03:55:41PM +, Brian Starkey wrote: On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote: On Tue, Jan 31, 2017 at 12:33:29PM +, Brian Starkey wrote: Hi, On Mon, Jan 30, 2017 at 03:35:13PM

Re: [PATCH 12/41] drm/bridge: analogix_dp: add fast link train for eDP

On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang > > We would meet a short black screen when exit PSR with the full link > training, In this case, we should use fast link train instead of full > link training. > > Signed-off-by: zain wang >

Re: DRM Atomic property for color-space conversion

On Thu, Mar 16, 2017 at 10:07 AM, Ville Syrjälä wrote: > On Tue, Jan 31, 2017 at 03:55:41PM +, Brian Starkey wrote: >> On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote: >> >On Tue, Jan 31, 2017 at 12:33:29PM +, Brian Starkey wrote: >> >> Hi, >>

Re: DRM Atomic property for color-space conversion

On Tue, Jan 31, 2017 at 03:55:41PM +, Brian Starkey wrote: > On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote: > >On Tue, Jan 31, 2017 at 12:33:29PM +, Brian Starkey wrote: > >> Hi, > >> > >> On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä wrote: > >> >On Fri, Jan 27,

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

On Wed, Mar 8, 2017 at 9:37 AM, Gustavo Padovan wrote: >> diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h >> index 2584c1cca42f6..e9c388a1d8ebe 100644 >> --- a/include/uapi/drm/etnaviv_drm.h >> +++ b/include/uapi/drm/etnaviv_drm.h >> @@ -154,6

[PATCH libdrm 1/2] xf86drm: add missing include

GCC 7 complains about major(), minor() and makedev(): warning: In the GNU C Library, "major" is defined by . For historical compatibility, it is currently defined by as well, but we plan to remove this soon. To use "major", include directly. If you did not intend to use a

[PATCH libdrm 2/2] libkms: add missing include

GCC 7 complains about major() and minor(): warning: In the GNU C Library, "major" is defined by . For historical compatibility, it is currently defined by as well, but we plan to remove this soon. To use "major", include directly. If you did not intend to use a system-defined

Re: [Intel-gfx] [PATCH v3] drm: Add DPCD definitions for DP 1.4 DSC feature

On Tue, 2017-03-14 at 13:01 -0700, Manasi Navare wrote: > From: "Navare, Manasi D" > > Display stream compression is supported on DP 1.4 DP > devices. This patch adds the corersponding DPCD > register definitions for DSC. > > v3: > * Add some SHIFTS and MASKS for

Re: [PATCH 10/41] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang > > There is a race between AUX CH bring-up and enabling bridge which will > cause link training to fail. To avoid hitting it, don't change psr state > while enabling the bridge. > > Cc: Tomeu Vizoso

[Bug 100101] [SNB GT1] GPU HANG: ecode 6:0:0x85deffbc, in gnome-shell [3664], reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=100101 --- Comment #5 from dergottdergrun...@gmail.com --- Created attachment 130258 --> https://bugs.freedesktop.org/attachment.cgi?id=130258=edit /sys/class/drm/card0/error Mar 16th -- You are receiving this mail because: You are the assignee for

[Bug 100101] [SNB GT1] GPU HANG: ecode 6:0:0x85deffbc, in gnome-shell [3664], reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=100101 --- Comment #4 from dergottdergrun...@gmail.com --- Happened again today. Video: https://www.youtube.com/watch?v=-n0Sg9wg2tM Video ID:-n0Sg9wg2tM Dimensions:1280 x 720 Resolution:1920 x 1080@60 Volume:18% Stream Host:r3---sn-mv-cvne Stream

Re: [PATCH v2] drm/atmel-hlcdc: Simplify the HLCDC layer logic

On Fri, 10 Feb 2017 19:07:45 +0100 Boris Brezillon wrote: > An HLCDC layers in Atmel's nomenclature is either a DRM plane or a 'Post > Processing Layer' which can be used to output the results of the HLCDC > composition in a memory buffer. > >

Re: [PATCH 08/41] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

On 10.03.2017 05:32, Sean Paul wrote: > From: Yakir Yang > > Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() > function, or print the sink PSR error state if we failed to apply the > requested PSR setting. > > Cc: 征增 王 > Cc:

Re: [PATCH] drm/atmel-hlcdc: Fix suspend/resume implementation

On Wed, 1 Mar 2017 13:31:01 +0100 Boris Brezillon wrote: > The current suspend resume implementation is assuming register values are > kept when entering suspend, which is no longer the case with the > suspend-to-RAM on the sama5d2. > > While at it, switch

[Bug 100222] Hang regression with R7 M370, identified possible culprit commit

https://bugs.freedesktop.org/show_bug.cgi?id=100222 --- Comment #4 from Alex Deucher --- (In reply to Mauro Santos from comment #3) > Build fails after applying patch 1 followed by patch 2 with: > > > drivers/gpu/drm/radeon/si_dpm.c: In function

Re: [PATCH 06/41] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang > > The bridge does not need to be powered in analogix_dp_bind(), so > remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp() > as well as their power-off counterparts. > > Cc: Stéphane Marchesin

[Bug 100222] Hang regression with R7 M370, identified possible culprit commit

https://bugs.freedesktop.org/show_bug.cgi?id=100222 --- Comment #3 from Mauro Santos --- Build fails after applying patch 1 followed by patch 2 with: drivers/gpu/drm/radeon/si_dpm.c: In function ‘si_get_vce_clock_voltage’: drivers/gpu/drm/radeon/si_dpm.c:2977:4:

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

https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #149 from alvarex --- I forgot to mention I had a similar problem on Windows also with a 260x on the same motherboard so I think in my case is something to do with the motherboard. I tried modyfing some

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

https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #148 from alvarex --- (In reply to Chris Waters from comment #133) > I decided to record how my system behaves when using Linux and my 390 > together. > > This is what I see

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

Hi Gustavo, On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote: [...] > I was thinking on some function that would iterate over all fences in > the fence_array and check their context. The if we find our own gpu > context in there we fail the submit. Why would we have to fail if somebody

Re: [PATCH v2 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

On Thu, 16 Mar 2017 11:31:44 +0800, Chris Zhong wrote: > For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is > disabled, MIPI phy can not work. Let's return a error if there is no > phy_cfg_clk in dts property, when the pdata match RK3399. > > Signed-off-by: Chris Zhong

[Bug 194899] triple fault while loading amdgpu on Cape Verde

https://bugzilla.kernel.org/show_bug.cgi?id=194899 --- Comment #2 from Janpieter Sollie (janpieter.sol...@dommel.be) --- Created attachment 255291 --> https://bugzilla.kernel.org/attachment.cgi?id=255291=edit /proc/kmsg with dpm=0 parameter -- You are receiving this mail because: You are

Re: [PATCH] drm/fb-helper: Only reject FB changes if FB_MISC_USER_EVENT is set

Hi, On 16 March 2017 at 09:55, Michel Dänzer wrote: > Otherwise this can also prevent modesets e.g. for switching VTs. > > FB_MISC_USER_EVENT is set when the request originates from userspace, > which is what we're interested in here according to the DRM_DEBUG > output. > >

  1   2   >