[GIT PULL] drm/fsl-dcu: fixes for v4.11

Hi Dave, Just two minor fixes this time around. -- Stefan The following changes since commit 4eaa39c63caf535dc1a8cc43b9a8677a100c09e1: Merge branch 'drm-rockchip-next-2017-02-07' of https://github.com/markyzq/kernel-drm-rockchip into drm-next (2017-02-08 11:28:19 +1000) are available in

Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc

On Wed, Feb 8, 2017 at 1:45 AM, Mark yao wrote: > On 2017年02月08日 00:14, Sean Paul wrote: >> >> On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote: >>> >>> drm crtc already has mode_fixup callback to can do mode check, but >>> We actually want to valid display mode

Re: [PATCH v2] drm/mxsfb: fix pixel clock polarity

On Wed, Feb 8, 2017 at 6:19 AM, Stefan Agner wrote: > On 2016-12-14 13:25, Marek Vasut wrote: >> On 12/14/2016 09:48 PM, Stefan Agner wrote: >>> The DRM subsystem specifies the pixel clock polarity from a >>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means >>> the

Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement

On Tue, Feb 7, 2017 at 11:31 PM, Marek Vasut wrote: > On 02/07/2017 11:15 PM, Daniel Vetter wrote: >> On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote: >>> On 02/02/2017 10:26 PM, Fabio Estevam wrote: From: Fabio Estevam Currently

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

On Wed, Feb 8, 2017 at 1:33 AM, Eric Anholt wrote: > Andrzej Pietrasiewicz writes: > >> When drm_crtc_init_with_planes() was orignally added >> (in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af >> drm: Add drm_crtc_init_with_planes() (v2)), it only

Re: [bug report] drm: zte: add overlay plane support

Oh. Also this one: drivers/gpu/drm/zte/zx_plane.c:253 zx_vl_plane_atomic_update() warn: always true condition '(fmt >= 0) => (0-u32max >= 0)' regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org

[bug report] drm: zte: add overlay plane support

Hello Shawn Guo, The patch 4e986d3705df: "drm: zte: add overlay plane support" from Nov 16, 2016, leads to the following static checker warning: drivers/gpu/drm/zte/zx_plane.c:170 zx_vl_rsz_setup() warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'

[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #3 from garththei...@hotmail.com --- Created attachment 129409 --> https://bugs.freedesktop.org/attachment.cgi?id=129409=edit lspci output -- You are receiving this mail because: You are the assignee for the

[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #2 from garththei...@hotmail.com --- GPU: XFX R9 390 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org

[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #1 from garththei...@hotmail.com --- Created attachment 129408 --> https://bugs.freedesktop.org/attachment.cgi?id=129408=edit Xorg.log -- You are receiving this mail because: You are the assignee for the

[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

https://bugs.freedesktop.org/show_bug.cgi?id=99710 Bug ID: 99710 Summary: [amdgpu R9 390] GPU hang when playing Hearthstone in Wine Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All)

Re: [PATCH v2] drm/mxsfb: fix pixel clock polarity

Dave, Marek, On 2016-12-14 13:25, Marek Vasut wrote: > On 12/14/2016 09:48 PM, Stefan Agner wrote: >> The DRM subsystem specifies the pixel clock polarity from a >> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means >> the controller drives the data on pixel clocks falling edge. >> That

Re: [PATCH 1/2] drm/fsl-dcu: remove unneeded 'ret' assignment

On 2016-12-28 08:48, Fabio Estevam wrote: > From: Fabio Estevam > > When devm_kzalloc() fails there is no need to assign an error code > to the 'ret' variable as it will not be used after jumping to the > 'err_node_put' label, so just remove the assignment. > >

Re: [PATCH v3 09/23] drm: fsl-dcu: use vblank hooks in struct drm_crtc_funcs

On 2017-02-07 01:16, Shawn Guo wrote: > From: Shawn Guo > > The vblank hooks in struct drm_driver are deprecated and only meant for > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks > in struct drm_crtc_funcs should be used instead. > >

[PATCH v6 0/6] Rockchip dw-mipi-dsi driver

Hi all This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of RK3399 is almost the same as RK3288, except a little bit of difference in phy clock controlling and port id selection register. These patches add RK3399 support and the power domain support. And these patches base on

[PATCH v6 1/6] dt-bindings: add rk3399 support for dw-mipi-rockchip

The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has additional phy config clock. Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None

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

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 phy init. Signed-off-by: Chris Zhong

[PATCH v6 4/6] drm/rockchip/dsi: remove mode_valid function

The MIPI DSI do not need check the validity of resolution, the max resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid here. Signed-off-by: Chris Zhong --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None

[PATCH v6 5/6] dt-bindings: add power domain node for dw-mipi-rockchip

Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 3 +++ 1 file changed, 3 insertions(+) diff

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

correct the coding style, according the checkpatch scripts Signed-off-by: Chris Zhong Reviewed-by: Sean Paul --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 29

[PATCH v6 6/6] drm/rockchip/dsi: add dw-mipi power domain support

Reference the power domain incase dw-mipi power down when in use. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16

[Bug 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted

https://bugs.freedesktop.org/show_bug.cgi?id=99444 --- Comment #19 from Shmerl --- (In reply to Samuel Pitoiset from comment #16) > Does the following patch help? > > https://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=dfe111368d11aaffae7f8738c858c335cdec1e9d > > It

Re: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu

On 2017年02月07日 20:38, Thierry Reding wrote: On Tue, Feb 07, 2017 at 04:35:35PM +0800, Mark Yao wrote: Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and enable on ARM64" already landed, So drm/rockchip related patches [1] and [2] ready to landed, this series just rebase them to

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

Hi Jani, On 07-02-2017 13:35, Jani Nikula wrote: > On Tue, 07 Feb 2017, Jose Abreu wrote: >>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter) >>> +{ >>> + u8 status; >>> + int ret; >>> + >>> + ret = drm_scdc_readb(adapter,

Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code

Hi Shawn, On Tue, 2017-02-07 at 17:16 +0800, Shawn Guo wrote: > From: Shawn Guo > > Core code already makes drm_driver.get_vblank_counter hook optional by > letting drm_vblank_no_hw_counter be the default implementation for the > function hook.  So the

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

On 02/01/2017 06:19 PM, 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 drm_panel_prepare() and >

Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement

On 02/07/2017 11:15 PM, Daniel Vetter wrote: > On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote: >> On 02/02/2017 10:26 PM, Fabio Estevam wrote: >>> From: Fabio Estevam >>> >>> Currently the framebuffer content is displayed with incorrect offsets >>> in both the

Re: [PATCH 2/5] arm64: dts: exynos: Move the clock-frequency property

Hi, I think the subject is not really matching the real work. You are rather removing the OF graph from DSI node. On Mon, Feb 06, 2017 at 11:19:41AM +0900, Hoegeun Kwon wrote: > The OF graph is not needed because the panel is a child of dsi. So > removed the ports and moved burst, esc

Re: [PATCH v2 1/6] drm: Add SCDC helpers

Hi Shashank, Sorry for the late review. On 06-02-2017 13:59, Shashank Sharma wrote: > From: Thierry Reding > > SCDC is a mechanism defined in the HDMI 2.0 specification that allows > the source and sink devices to communicate. > > This commit introduces helpers to access

Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement

On 02/02/2017 10:26 PM, Fabio Estevam wrote: > From: Fabio Estevam > > Currently the framebuffer content is displayed with incorrect offsets > in both the vertical and horizontal directions. > > The fbdev version of the driver does not show this problem. Breno Lima >

Re: [PATCH v2 2/6] drm/edid: check for HF-VSDB block

Hi Shashank, On 06-02-2017 13:59, Shashank Sharma wrote: > From: Thierry Reding > > This patch implements a small function that finds if a > given CEA db is hdmi-forum vendor specific data block > or not. > > Signed-off-by: Thierry Reding >

Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code

On Tue, Feb 07, 2017 at 12:42:15PM +0200, Laurent Pinchart wrote: > On an unrelated note, for security reasons we should try to make the driver > structure static, or at least move ops to a static structure. ITYM "const" not "static". "static" doesn't get you anything from a security point of

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

Hi Shashank, On 06-02-2017 13:59, 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 advanced HDMI 2.0 features > - Adds another structure drm_scdc within

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

Hi Shashank, On 06-02-2017 13:59, Shashank Sharma wrote: > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > than 340 MHz. This patch adds few new functions in drm layer for > core drivers to enable/disable scrambling. > > This patch adds: > - A function to detect scrambling

Re: [PATCH v3 06/23] drm: armada: use vblank hooks in struct drm_crtc_funcs

On Tue, Feb 07, 2017 at 05:16:18PM +0800, Shawn Guo wrote: > From: Shawn Guo > > The vblank hooks in struct drm_driver are deprecated and only meant for > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks > in struct drm_crtc_funcs should be used

Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code

On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote: For: > drivers/gpu/drm/armada/armada_drv.c | 1 - Acked-by: Russell King -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #67 from Michel Dänzer --- The patch forces most buffers to GTT, which is clearly a bad idea with a dedicated GPU. Marek, what theory did you want to test with this patch? -- You are receiving this mail

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On 7 February 2017 at 14:49, Chris Wilson wrote: > On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: >> On 7 February 2017 at 14:29, Daniel Vetter wrote: >> > Noticed that everyone duplicates the same logic here and we could safe >> >

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

On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote: > Except I have no way of knowing whether: a) you omitted a supply > because you don't (yet) care, b) the panel has a single supply and you > are using power-supply or c) the panel has multiple supplies and your > binding is

Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc

On 2017年02月08日 00:14, Sean Paul wrote: On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote: drm crtc already has mode_fixup callback to can do mode check, but We actually want to valid display mode on connector getmode time, mode_fixup can't do it. So add a private mode_valid callback to

Re: [patch] drm/radeon: remove some dead code

On 07/02/17 10:16 PM, Dan Carpenter wrote: > If "rdev->bios" is NULL then we don't need to free it. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/gpu/drm/radeon/radeon_bios.c > b/drivers/gpu/drm/radeon/radeon_bios.c > index 00cfb5d2875f..04c0ed41374f

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

Andrzej Pietrasiewicz writes: > 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

Re: [PATCH v2 3/7] drm/rockchip: gem: add mutex lock for drm mm

On 2017年02月07日 20:19, Thierry Reding wrote: On Tue, Feb 07, 2017 at 04:35:38PM +0800, Mark Yao wrote: drm_mm_insert_node_generic and drm_mm_remove_node may access same resource with list ops, it's not threads safe, so protect this context with mutex lock. Fix bug: [49451.856244]

Re: [PATCH] drm/vc4: simplify exit path of a failed allocation of dsi_connector

Colin King writes: > From: Colin Ian King > > If dsi_connector fails to allocate, the exit path via label 'fail' > checks if connector is null, which it always is, so the cleanup > that destroys connector is never going to be called. Hence

[patch] drm/atomic: fix an error code in mode_fixup()

Having "ret" be a bool type works for everything except ret = funcs->atomic_check(). The other functions all return zero on error but ->atomic_check() returns negative error codes. We want to propagate the error code but instead we return 1. I found this bug with static analysis and I don't

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

On Tue, Feb 7, 2017 at 12:55 PM, Fabio Estevam wrote: > Hi Rob, > > On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote: > >> No power supply(ies) for this panel? > > power-supply is mentioned in simple-panel.txt. > >>> +This binding is compatible with the

Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement

On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote: > On 02/02/2017 10:26 PM, Fabio Estevam wrote: > > From: Fabio Estevam > > > > Currently the framebuffer content is displayed with incorrect offsets > > in both the vertical and horizontal directions. > > > >

[Bug 98634] Fedora/Ubuntu 32bits is not able to resume from hibernate

https://bugs.freedesktop.org/show_bug.cgi?id=98634 --- Comment #2 from Humberto Israel Perez Rodriguez --- the issue still occurs with the following configuration on SKL == Software

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #66 from Captain Crutches --- I'm having the same results as everyone else with the patch: hanging seems diminished, FPS down noticeably (in multiplayer, not free play) but still playable. Patched mesa

[PATCH 1/3] dt-bindings: Document the dmas and dma-names properties for VC4 HDMI

From: Boris Brezillon These are optional, but necessary for HDMI audio support. Signed-off-by: Boris Brezillon Signed-off-by: Eric Anholt --- Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt |

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

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 driver has been considered here, but MAI meant

[PATCH 3/3] ARM: dts: bcm283x: Add HDMI audio related properties

From: Boris Brezillon Add the dmas and dma-names properties to support HDMI audio. Signed-off-by: Boris Brezillon Signed-off-by: Eric Anholt --- arch/arm/boot/dts/bcm283x.dtsi | 2 ++ 1 file changed, 2

[Bug 98869] Electronic Super Joy graphic artefacts (regression)

https://bugs.freedesktop.org/show_bug.cgi?id=98869 --- Comment #18 from cosiek...@o2.pl --- I have compiled couple of times. Here are my results. b7da8fa11d5c6ec71113350eed1959191a7d5990 working 84b961dd53a0509a6865d8417301838b34a40096 working e54b2e902aba22f697c0ba8622cd0a905f1edfff working

Re: [PATCH] drm/doc: Add TODO list

On Tue, Feb 07, 2017 at 06:51:13PM +0100, Thierry Reding wrote: > From: Thierry Reding > > This commit adds a TODO list to the GPU driver developer's guide. The > content was taken from the DRMJanitors page on the X.Org wiki: > > https://www.x.org/wiki/DRMJanitors/ >

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

Hi Rob, On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote: > No power supply(ies) for this panel? power-supply is mentioned in simple-panel.txt. >> +This binding is compatible with the simple-panel binding, which is specified >> +in simple-panel.txt in this directory. and

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

On Thu, Feb 02, 2017 at 06:04:00PM -0200, Breno Lima wrote: > Add support for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) > TFT with Touch-Panel, which can be supported by the simple panel driver. > > Data-sheet available at: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf > >

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #65 from andrei.demin1...@gmail.com --- > Got it tested on another system with a rx470. >The hangs are mostly gone, but fps drops from 60+ to ~25. (btw the patch was >>applied to mesa 13.0.0.4) Yep, same. FPS drops from 60+ to 30-40

[PATCH] drm/doc: Add TODO list

From: Thierry Reding This commit adds a TODO list to the GPU driver developer's guide. The content was taken from the DRMJanitors page on the X.Org wiki: https://www.x.org/wiki/DRMJanitors/ The goal is to track a list of refactorings that would be nice to see merged

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

Am Dienstag, den 07.02.2017, 17:45 +0100 schrieb Philipp Zabel: > On Fri, 2017-02-03 at 10:52 -0200, Fabio Estevam wrote: > > Hi Philipp, > > > > On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam wrote: > > > From: Fabio Estevam > > > > > > Commit

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #64 from freedesk...@bremsspur.org --- Got it tested on another system with a rx470. The hangs are mostly gone, but fps drops from 60+ to ~25. (btw the patch was applied to mesa 13.0.0.4) -- You are receiving this mail because: You

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

Hi Philipp, On Tue, Feb 7, 2017 at 2:45 PM, Philipp Zabel wrote: > I've applied this to the fixes branch, since the current device trees > don't have the regulator set. I have sent a patch providing the dac-supply regulator for imx53-qsb:

[PATCH v3 1/2] drm: mali-dp: add malidp_crtc_state struct

Add a custom CRTC state struct to enable storing driver-private per-CRTC state. This patch only adds the base drm_crtc_state struct. Signed-off-by: Mihail Atanassov Reviewed-by: Brian Starkey Acked-by: Liviu Dudau --- Link

[PATCH v3 2/2] drm: mali-dp: enable gamma support

Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC properties. The expected LUT size is 4096 in order to produce as accurate a set of segments as possible. This version uses only the green channel's gamma curve to set the hardware curve on DP550/650. For the sake of simplicity, it uses the same

Re: [PATCH 0/2] drm/panel: Add support for the Sitronix ST7789V

On Tue, Feb 07, 2017 at 04:34:44PM +0100, Maxime Ripard wrote: > On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote: > > > > Den 06.02.2017 11.39, skrev Maxime Ripard: > > > Hi Noralf, > > > > > > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote: > > > > Den 03.02.2017

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

On Fri, 2017-02-03 at 10:52 -0200, Fabio Estevam wrote: > Hi Philipp, > > On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam wrote: > > From: Fabio Estevam > > > > Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by > >

Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel

On Tue, Feb 07, 2017 at 04:44:42PM +0100, Maxime Ripard wrote: > Hi Thierry, > > On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote: > > On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote: > > > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that > >

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

On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 2/7/2017 4:31 PM, Jose Abreu wrote: > > Hi Shashank, > > > > > > > > On 06-02-2017 13:59, Shashank Sharma wrote: > > > This patch does following: > > > - Adds a new structure (drm_hdmi_info) in

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 05:16:03PM +0100, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > v2: Forgot to git add everything :( > > v3: Actually remove

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

Regards Shashank On 2/7/2017 4:44 PM, Jose Abreu wrote: Hi Shashank, On 06-02-2017 13:59, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340 MHz. This patch adds few new functions in drm layer for core drivers to enable/disable scrambling.

[PATCH] drm/fb-helper: Automatically clean up fb_info

Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! v2: Forgot to git add everything :( v3: Actually remove release_fbi (Sean, Emil, Chris) ... Cc: Chris Wilson

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

On Sun, Feb 05, 2017 at 11:54:10AM +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

Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc

On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote: > drm crtc already has mode_fixup callback to can do mode check, but > We actually want to valid display mode on connector getmode time, > mode_fixup can't do it. > > So add a private mode_valid callback to rockchip crtc, connectors can >

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

Regards Shashank On 2/7/2017 4:31 PM, Jose Abreu wrote: Hi Shashank, On 06-02-2017 13:59, 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 advanced HDMI 2.0

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 02:49:38PM +, Chris Wilson wrote: > On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: > > On 7 February 2017 at 14:29, Daniel Vetter wrote: > > > Noticed that everyone duplicates the same logic here and we could safe > > > a few

Re: [PATCH v2 1/6] drm: Add SCDC helpers

Thanks for the review Jose, my comments inline. Regards Shashank On 2/7/2017 4:24 PM, Jose Abreu wrote: Hi Shashank, Sorry for the late review. On 06-02-2017 13:59, Shashank Sharma wrote: From: Thierry Reding SCDC is a mechanism defined in the HDMI 2.0

Re: [PATCH] drm/rockchip: cdn-dp: fix cdn-dp complie warning

On Tue, Feb 07, 2017 at 09:34:01AM +0800, Mark Yao wrote: > fix warning: > > drivers/gpu/drm/rockchip/cdn-dp-reg.c:632:24: warning: > 'val[1]' may be used uninitialized in this function [-Wmaybe-uninitialized] > msa_misc = 2 * val[0] + 32 * val[1] + > > Signed-off-by: Mark Yao

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

Regards Shashank On 2/7/2017 3:51 PM, Jani Nikula wrote: On Mon, 06 Feb 2017, Shashank Sharma wrote: Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher

Re: [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > Cc: Chris Wilson > Cc: Sean Paul

Re: [PATCH 2/2] drm/panel: Add driver for sitronix ST7789V panel

On Mon, Feb 06, 2017 at 02:26:20PM +0100, Thierry Reding wrote: > > +#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > > +#define st7789v_send(ctx, cmd, ...) > > \ > > + st7789v_write_command_data(ctx, cmd, NUMARGS(__VA_ARGS__), \ >

Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel

Hi Thierry, On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote: > On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote: > > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that > > can drive 18-bits 240x320 LCD displays. > > > > Signed-off-by: Maxime

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > SKL+ display engine can scan out certain kinds of compressed surfaces > produced by the render engine. This involved telling the display engine > the location

Re: [PATCH v3 17/23] drm: rockchip: remove struct rockchip_crtc_funcs

On Tue, Feb 07, 2017 at 05:16:29PM +0800, Shawn Guo wrote: > From: Shawn Guo > > With the vblank hooks in struct drm_crtc_funcs, we do not need to > maintain struct rockchip_crtc_funcs and the related registration > functions. Remove them. > Reviewed-by: Sean Paul

Re: [PATCH 0/2] drm/panel: Add support for the Sitronix ST7789V

On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote: > > Den 06.02.2017 11.39, skrev Maxime Ripard: > > Hi Noralf, > > > > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote: > > > Den 03.02.2017 10.59, skrev Maxime Ripard: > > > > Hi, > > > > > > > > Here is an attempt

Re: [PATCH v3 23/23] drm: zte: use vblank hooks in struct drm_crtc_funcs

On Tue, Feb 07, 2017 at 05:16:35PM +0800, Shawn Guo wrote: > From: Shawn Guo > > The vblank hooks in struct drm_driver are deprecated and only meant for > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks > in struct drm_crtc_funcs should be used

Re: [PATCH v3 05/23] drm: malidp: use vblank hooks in struct drm_crtc_funcs

On Tue, Feb 07, 2017 at 05:16:17PM +0800, Shawn Guo wrote: > From: Shawn Guo > > The vblank hooks in struct drm_driver are deprecated and only meant for > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks > in struct drm_crtc_funcs should be used

Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code

On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote: > From: Shawn Guo > > Core code already makes drm_driver.get_vblank_counter hook optional by > letting drm_vblank_no_hw_counter be the default implementation for the > function hook. So the drm_vblank_no_hw_counter

Re: [PATCH libdrm] intel: avoid null pointer dereference

On Tuesday, 2017-02-07 15:59:32 +0100, Thomas H.P. Andersen wrote: > On Fri, Feb 3, 2017 at 11:57 AM, Eric Engestrom > wrote: > > > > On Thursday, 2017-02-02 23:57:29 +0100, Thomas Hindoe Paaboel Andersen > > wrote: > > > Introduced in 028715ee > > > > > > Move the

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

On Tue, 07 Feb 2017, Jose Abreu wrote: > Hi Jani, > > > On 07-02-2017 13:35, Jani Nikula wrote: >> On Tue, 07 Feb 2017, Jose Abreu wrote: +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter) +{ + u8 status; +

Re: [PATCH libdrm] intel: avoid null pointer dereference

On Fri, Feb 3, 2017 at 11:57 AM, Eric Engestrom wrote: > > On Thursday, 2017-02-02 23:57:29 +0100, Thomas Hindoe Paaboel Andersen wrote: > > Introduced in 028715ee > > > > Move the dereference after the null check. > > Fixes: 028715ee707469189505 ("intel: Avoid the need

[patch v2] drm/i915/gvt/kvmgt: remove some dead code

"caps.buf" is always NULL here and "caps.size" is always zero. The code is a no-op and can be removed. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 3f656e3a6e5a..773a45aa18f8 100644 ---

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: > On 7 February 2017 at 14:29, Daniel Vetter wrote: > > Noticed that everyone duplicates the same logic here and we could safe > > a few lines per driver. Yay for lots of drivers to make such tiny > > refactors

[Bug 99136] Blood Effects Total War: Warhammer

https://bugs.freedesktop.org/show_bug.cgi?id=99136 --- Comment #21 from siyia --- (In reply to Gregor Münch from comment #20) > (In reply to Samuel Pitoiset from comment #19) > > Created attachment 129356 [details] > > no blood effects option (v 1.5) > > Maybe you need

Re: [Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code

On Tue, Feb 07, 2017 at 04:34:57PM +0200, Joonas Lahtinen wrote: > On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote: > > If "caps.buf" is already NULL then it doesn't need to be freed or set to > > NULL. > > > > Signed-off-by: Dan Carpenter > > > > > @@ -965,11

[PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

Let's disable all scaling that requires horizontal decimation with higher factor than 4, until we have better estimates of what we can and can not do. However, 1 byte per pixel color format appear to work Ok with all decimation factors. When decimating horizontally by more that 4 the dss is not

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On 7 February 2017 at 14:29, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > v2: Forgot to git add everything :( > Hmm afaict this

Re: [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 5220a7b5e6ff..074ab22a7cf3 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -781,7 +781,9 @@

Re: [Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code

On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote: > If "caps.buf" is already NULL then it doesn't need to be freed or set to > NULL. > > Signed-off-by: Dan Carpenter > @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, > unsigned int

[PATCH] drm/fb-helper: Automatically clean up fb_info

Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! v2: Forgot to git add everything :( Cc: Chris Wilson Cc: Sean Paul Cc: Noralf Trønnes

Re: [PATCH 1/2] drm/fb-helper: Explain unload sequence a bit better

On Tue, Feb 07, 2017 at 03:10:49PM +0100, Daniel Vetter wrote: > While reviewing Chris' patches to properly cancel our async workers I > checked that this happens after the fbdev is already unregistered. > That's the case, but I found a small gap in our docs, fill that in. > > Note that I don't

[PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! Cc: Chris Wilson Cc: Sean Paul Cc: Noralf Trønnes Signed-off-by:

  1   2   >