[Bug 196269] [amdgpu][tahiti xt] dota2 crashes randomly in game

https://bugzilla.kernel.org/show_bug.cgi?id=196269 Sylvain BERTRAND (sylvain.bertr...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH v3] drm/edid: rename macro for CEA extended-tag

/20170704-114852 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: x86_64-randconfig-x015-07041133 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error

[Bug 101683] Some games hang while loading when compositing is shut off or absent

https://bugs.freedesktop.org/show_bug.cgi?id=101683 --- Comment #6 from Michel Dänzer --- The patch I just attached to bug 97957 fixes the Warzone2100 hangs for me as well. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 1/2] video/hdmi: Allow "empty" HDMI infoframes

On Tue, Jul 04, 2017 at 11:41:27AM +0200, Andrzej Hajda wrote: > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > HDMI 2.0 Appendix F suggest that we should keep sending the infoframe > > when switching from 3D to 2D mode,

Re: [PATCH libdrm] amdgpu: move asic id table to a separate file

2017-06-12 17:50 GMT+08:00 Michel Dänzer : > From: Xiaojie Yuan > > v2: fix an off by one error and leading white spaces > v3: use thread safe strtok_r(); initialize len before calling getline(); > change printf() to drmMsg(); add initial amdgpu.ids >

[Bug 101685] [amdgpu][tahiti xt] dota2 random crash

https://bugs.freedesktop.org/show_bug.cgi?id=101685 Bug ID: 101685 Summary: [amdgpu][tahiti xt] dota2 random crash Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Mon, Jul 03, 2017 at 10:19:38PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from > 3D to 2D mode in a timely fashion if the source simply stops sending the > HDMI

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from > 3D to 2D mode in a timely fashion if the source simply stops sending the > HDMI infoframe. The suggested

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from > > 3D to 2D mode in a timely fashion if

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

Hi! > Are you sure it doesn't probe? It fails the omapdss_stack_is_ready() > check? > >>> > >>> It appears the reason was that I didn't have > >>> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled. > >>> > >>> I think that's wrong. I don't own an analog TV, so why should I enable > >>> such

[PATCH v5 12/17] drm/i915: add compute-config for YCBCR outputs

This patch checks encoder level support for HDMI YCBCR outputs. HDMI output mode is a connector property, this patch checks if source and sink can support the HDMI output type selected by user. And if they both can, it commits the hdmi output type into crtc state, for further staging in driver.

[PATCH v5 17/17] drm/i915/glk: set HDMI 2.0 identifier

This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID handling functions to save lot of work which is specific to HDMI 2.0 sources. V3: Added this patch V4: Rebase V4: Rebase V4: Added r-b from

[PATCH v5 13/17] drm/i915: prepare scaler for YCBCR420 modeset

To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI ycbcr420 outputs. - Programs PIPE_MISC register for ycbcr420 output. - Adds a new scaler user "HDMI output" to plug-into existing

[PATCH v5 10/17] drm: set output colorspace in AVI infoframe

HDMI source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. As this patch series is adding support for HDMI output modes other than RGB, this patch adds a function in DRM layer, to add the output colorspace information in the AVI

[PATCH v5 16/17] drm/i915: set colorspace for ycbcr outputs

When HDMI output is other than RGB, we have to load the corresponding colorspace of output mode. This patch fills the colorspace of AVI infoframe as per the HDMI output mode. V2: Rebase V3: Rebase V4: Rebase V5: Added r-b from Ander Cc: Ville Syrjala Cc: Ander

[PATCH v5 06/17] drm/edid: rename macro for CEA extended-tag

CEA-861-F introduces extended tag codes for EDID extension blocks, which indicates the actual type of the data block. The code for using exteded tag is 0x7, whereas in the existing code, the corresponding macro is named as "VIDEO_CAPABILITY_BLOCK" This patch renames the macro and usages from

[PATCH v5 11/17] drm: add helper functions for YCBCR output handling

This patch adds set of helper functions for YCBCR HDMI output handling. These functions provide functionality like: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 mode. - get the highest subsamled ycbcr output. - get the lowest subsamled ycbcr

[PATCH v5 01/17] drm: add HDMI 2.0 VIC support for AVI info-frames

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if

[PATCH v5 00/17] HDMI YCBCR output handling in DRM layer

This patch series adds support for YCBCR HDMI output handling in DRM layer. The main aim of this patch series was to handle YCBCR 4:2:0 output for HDMI 2.0 displays. But while providing a framework to handle non-RGB outputs, support for YCBCR 4:4:4 and 4:2:2 was also added. First 2 patches,

[PATCH v5 02/17] drm: add YCBCR 420 capability identifier

This patch adds a bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is capable of handling YCBCR 420 outputs or not, so that a lot of work can be done/bypassed based on this information. One such

[PATCH v5 03/17] drm/edid: Complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65

[PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds a drm helper to validate YCBCR420-only mode on a particular connector. This function will help pruning the YCBCR420-only modes from the connector's modelist. V5: Introduced the patch in series. Cc: Ville Syrjala

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote: > On 04.07.2017 14:44, Ville Syrjälä wrote: > > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: > >> On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > >>> From: Ville Syrjälä >

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

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

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

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

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

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

[PATCH 11/13] drm/i915: Protect against deferred fbdev setup

We could probably hit this already with our current async fbdev init, but it's much easier to hit this with the new deferred fbdev setup that I'm working on polishing. Cc: Maarten Lankhorst Reported-by: Maarten Lankhorst

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

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

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

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

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

On Tue, Jun 27, 2017 at 11:42:53AM -0400, Harry Wentland wrote: > On 2017-06-27 10:59 AM, Daniel Vetter wrote: > > Too jarring. > > > > Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic > > helpers (v2)") > > Cc: Andrey Grodzovsky > > Cc: Alex

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

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

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

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

Re: [PATCH] drm: ttm: vmwgfx: dma-buf: Constify ttm_place structures.

Looks good. Thanks. I've queued this for my next pull request. On Sun, Jul 02, 2017 at 01:26:55PM +0530, Arvind Yadav wrote: > ttm_place are not supposed to change at runtime. All functions > working with ttm_place provided by work > with const ttm_place. So mark the non-const structs as

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On 04.07.2017 14:44, Ville Syrjälä wrote: > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: >> On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: >>> From: Ville Syrjälä >>> >>> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch

Re: [PATCH v2 3/4] drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper

Den 28.06.2017 19.12, skrev Daniel Vetter: On Wed, Jun 28, 2017 at 04:26:23PM +0200, Noralf Trønnes wrote: Den 26.06.2017 11.43, skrev Daniel Vetter: On Thu, Jun 08, 2017 at 05:14:34PM +0200, Noralf Trønnes wrote: Drm has no monochrome or greyscale support so add a conversion from the common

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On 04.07.2017 16:25, Ville Syrjälä wrote: > On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote: >> On 04.07.2017 14:44, Ville Syrjälä wrote: >>> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > From:

[PATCH 00/13] fbdev locking + deferred setup take 3

Hi all, Here's the locking patches respun with Maarten's review. I think that part is ready for merging. The deferred setup itself needs more thought, since both Maarten and Liviu are still unhappy with what happens between the deferred setup and fbcon. Cheers, Daniel Daniel Vetter (9):

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

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

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

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

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

From: Thierry Reding Move the modeset locking from drivers into FB helpers. v2: Also handle intel_connector_add_to_fbdev. v3: Prevent race in intel_dp_mst with ->detect (Maarten) Cc: Maarten Lankhorst Cc: Alex Deucher

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

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

[PATCH v5 08/17] drm/edid: parse ycbcr 420 deep color information

CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase V4: Moved definition of

[PATCH v5 09/17] drm: create hdmi output property

HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB - YCBCR 444 - YCBCR 422 - YCBCR 420 This patch adds a drm property "hdmi_output_format", using which, a user can specify its preference,

[PATCH v5 15/17] drm/i915: prepare csc unit for YCBCR HDMI output

To support ycbcr HDMI output, we need a pipe CSC block to do the RGB->YCBCR conversion, as the blender output is in RGB. Current Intel platforms have only one pipe CSC unit, so we can either do color correction using it, or we can perform RGB->YCBCR conversion. This function adds a csc handler,

[PATCH v5 07/17] drm/edid: parse YCBCR 420 videomodes from EDID

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 output capabilities. These blocks are: - YCBCR420vdb(YCBCR 420 video data block): This block contains VICs of video modes, which

[PATCH v5 14/17] drm/i915: prepare pipe for YCBCR output

To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in full blend mode to use the scaler in 5x3 ratio (bits 26 and 27) This patch: - Adds definition of these bits. - Programs PIPEMISC

[PATCH v5 05/17] drm/edid: parse sink information before CEA blocks

CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Tue, Jul 04, 2017 at 05:09:36PM +0200, Andrzej Hajda wrote: > On 04.07.2017 16:25, Ville Syrjälä wrote: > > On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote: > >> On 04.07.2017 14:44, Ville Syrjälä wrote: > >>> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: >

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

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

Re: [PATCH 07/12] drm: export drm_gem_prime_dmabuf_ops

On Tue, Jul 04, 2017 at 02:55:00PM +1000, Dave Airlie wrote: > On 4 Jul. 2017 11:23, "Michel Dänzer" wrote: > > > Adding the dri-devel list, since this is a core DRM patch. > > > On 04/07/17 06:11 AM, Felix Kuehling wrote: > > From: Christian König

Re: [PATCH 07/12] drm: export drm_gem_prime_dmabuf_ops

Am 04.07.2017 um 08:26 schrieb Daniel Vetter: On Tue, Jul 04, 2017 at 02:55:00PM +1000, Dave Airlie wrote: On 4 Jul. 2017 11:23, "Michel Dänzer" wrote: Adding the dri-devel list, since this is a core DRM patch. On 04/07/17 06:11 AM, Felix Kuehling wrote: From:

Re: [PATCH 1/2] video/hdmi: Allow "empty" HDMI infoframes

On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > HDMI 2.0 Appendix F suggest that we should keep sending the infoframe > when switching from 3D to 2D mode, even if the infoframe isn't strictly > necessary (ie. not needed to

Re: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name

Hi Sam, do you also have a Mesa patch showing how the new APIs will be used? Without seeing that, some minor comments below. On 01/07/17 04:25 AM, Samuel Li wrote: > > +//#include > +//#include Remove these lines. > +#include "util/util_asic_id.h" Patch 1 adds the util directory to

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

On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote: > HDMI displays can support various output types, based on > the color space and subsampling type. The possible > outputs from a HDMI 2.0 monitor could be: > - RGB > - YCBCR 444 > - YCBCR 422 > - YCBCR 420 > > This patch adds a

Re: [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote: > YCBCR420 modes are supported only on HDMI 2.0 capable sources. > This patch adds a drm helper to validate YCBCR420-only mode > on a particular connector. This function will help pruning > the YCBCR420-only modes from the

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

On Tue, Jul 4, 2017 at 5:40 PM, Ville Syrjälä wrote: >> + mutex_lock(_helper->dev->mode_config.mutex); >> drm_enable_connectors(fb_helper, enabled); >> + if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0) > > This changes the order

[PATCH v1 3/3] drm/panel: Add support for otm8009a panel driver

This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD panel driver (MIPI-DSI video mode). The panel backlight is managed through the DSI link. This panel driver is used in several STM32 boards. Signed-off-by: Philippe CORNU --- drivers/gpu/drm/panel/Kconfig

[PATCH v1 0/3] Add support for the otm8009a dsi panel

Hi all, The purpose of this patch is to add support for the Orise Tech otm8009a 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode). This LCD panel is used in several STM32 boards. Version 1: - Initial commit Best regards, Philippe Philippe CORNU (3): dt-bindings: Add vendor prefix for Orise

[PATCH][drm-next] drm compat: ensure mode in drm_agp_info is being copied

From: Colin Ian King A recent compat change removed the copying of i32.mode from info.mode. Add it back in to fix this removal as we currently are leaking information from the stack. Detected by CoverityScan, CID#1449374 ("Unitialized scalar variable") Fixes:

[Bug 101695] mesa fails to compile illegal conversion of »int« in »radeon_bo_domain«

https://bugs.freedesktop.org/show_bug.cgi?id=101695 Bug ID: 101695 Summary: mesa fails to compile illegal conversion of »int« in »radeon_bo_domain« Product: Mesa Version: git Hardware: Other OS: All

[Bug 196271] New: [AMD] Computer crashes when trying to execute any particle animation

https://bugzilla.kernel.org/show_bug.cgi?id=196271 Bug ID: 196271 Summary: [AMD] Computer crashes when trying to execute any particle animation Product: Drivers Version: 2.5 Kernel Version: 4.9.30-1-MANJARO Hardware:

[PATCH v1 2/3] dt-bindings: display: panel: Add support for Orise Tech otm8009a dsi panel

The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using a MIPI-DSI video interface. Its backlight is managed through the DSI link. Signed-off-by: Philippe CORNU --- .../bindings/display/panel/orisetech,otm8009a.txt| 20 1 file

[PATCH v1 1/3] dt-bindings: Add vendor prefix for Orise Technology

Orise Technology is headquartered in Taiwan and specializes in manufacture of Flat Panel Display Driver IC and Flat Panel Display Controller IC. Signed-off-by: Philippe CORNU --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+)

Re: [PATCH v2 3/4] drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper

On Tue, Jul 04, 2017 at 05:00:46PM +0200, Noralf Trønnes wrote: > > Den 28.06.2017 19.12, skrev Daniel Vetter: > > On Wed, Jun 28, 2017 at 04:26:23PM +0200, Noralf Trønnes wrote: > > > Den 26.06.2017 11.43, skrev Daniel Vetter: > > > > On Thu, Jun 08, 2017 at 05:14:34PM +0200, Noralf Trønnes

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

On Tue, Jul 04, 2017 at 05:18:28PM +0200, Daniel Vetter wrote: > Those are now all protected using fb_helper->lock. > > v2: We still need to hold mode_config.mutex right around calling > connector->fill_modes. > > v3: I forgot to hold mode_config.mutex while looking at > connector->status and

RE: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name

> do you also have a Mesa patch showing how the new APIs will be used? Sent out to mesa dev just now. > Remove these lines. Right. > Please consistently either use this, or don't add the util directory to the > include path anywhere. OK. > Put an empty line between declarations and statements.

[Bug 196247] AMD FirePro W5130M - Radeon driver - ring 0 stalled

https://bugzilla.kernel.org/show_bug.cgi?id=196247 guiscara...@gmail.com changed: What|Removed |Added CC||guiscara...@gmail.com ---

[Bug 196273] New: Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 Bug ID: 196273 Summary: Loss of video output and system freezes *ERROR* Couldn't read SADs: 0 Product: Drivers Version: 2.5 Kernel Version: 4.12.0 Hardware: All

[RFC] clk: inherit display clocks enabled by bootloader

The goal here is to support inheriting a display setup by bootloader, although there may also be some non-display related use-cases. Rough idea is to add a flag for clks and power domains that might already be enabled when kernel starts, and make corresponding fixups to clk enable/prepare_count

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #3 from Olaf H B (o...@seldiame.net) --- Created attachment 257359 --> https://bugzilla.kernel.org/attachment.cgi?id=257359=edit lspci verbose output for the vga card -- You are receiving this mail because: You are watching the

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #4 from Olaf H B (o...@seldiame.net) --- Created attachment 257361 --> https://bugzilla.kernel.org/attachment.cgi?id=257361=edit kernel.log (fragment) -- You are receiving this mail because: You are watching the assignee of the

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #5 from Olaf H B (o...@seldiame.net) --- Created attachment 257363 --> https://bugzilla.kernel.org/attachment.cgi?id=257363=edit some debug msgs for amdgpu powerplay code I don't know if this useful but I added some extra prints in

Re: [PATCH v2 3/4] drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper

Den 04.07.2017 17.28, skrev Daniel Vetter: On Tue, Jul 04, 2017 at 05:00:46PM +0200, Noralf Trønnes wrote: Den 28.06.2017 19.12, skrev Daniel Vetter: On Wed, Jun 28, 2017 at 04:26:23PM +0200, Noralf Trønnes wrote: Den 26.06.2017 11.43, skrev Daniel Vetter: On Thu, Jun 08, 2017 at 05:14:34PM

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

https://bugs.freedesktop.org/show_bug.cgi?id=100742 --- Comment #1 from Felix Hellmann --- I can observe the same behaviour. Setting power_dpm_force_performance_level to high reduces ans smoothes out the StreamVr Compositor frame timings. Even when no "real" app is running (so

Re: [PATCH v8] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

Hi, On Sun, Jul 02, 2017 at 05:27:10PM +1000, Jonathan Liu wrote: > The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states: > "As in the general case the DDC bus is accessible by the kernel at the I2C > level, drivers must make all reasonable efforts to expose it as an I2C >

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

On Tue, Jul 04, 2017 at 05:18:30PM +0200, Daniel Vetter wrote: > FB helper code falls back to a 1024x768 mode if no outputs are connected > or don't report back any modes upon initialization. This can be annoying > because outputs that are added to FB helper later on can't be used with > FB helper

Re: [PATCH v5 02/17] drm: add YCBCR 420 capability identifier

On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote: > This patch adds a bool variable (ycbcr_420_allowed) in the drm connector > structure. While handling the EDID from HDMI 2.0 sinks, its important to > know if the source is capable of handling YCBCR 420 outputs or not, so that > a

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #1 from Olaf H B (o...@seldiame.net) --- Created attachment 257355 --> https://bugzilla.kernel.org/attachment.cgi?id=257355=edit dmesg output -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #2 from Olaf H B (o...@seldiame.net) --- Created attachment 257357 --> https://bugzilla.kernel.org/attachment.cgi?id=257357=edit configuration used in the kernel -- You are receiving this mail because: You are watching the

Re: [RFC] clk: inherit display clocks enabled by bootloader

On Tue, Jul 4, 2017 at 7:51 PM, Rob Clark wrote: > The goal here is to support inheriting a display setup by bootloader, > although there may also be some non-display related use-cases. > > Rough idea is to add a flag for clks and power domains that might > already be enabled

Re: [RFC] clk: inherit display clocks enabled by bootloader

On Tue, Jul 4, 2017 at 2:45 PM, Geert Uytterhoeven wrote: > On Tue, Jul 4, 2017 at 7:51 PM, Rob Clark wrote: >> The goal here is to support inheriting a display setup by bootloader, >> although there may also be some non-display related use-cases. >> >>

Re: [PATCH v5 02/17] drm: add YCBCR 420 capability identifier

Regards Shashank On 7/4/2017 9:25 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote: This patch adds a bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is

[Bug 101596] Blender renders black UI elements

https://bugs.freedesktop.org/show_bug.cgi?id=101596 Michel Dänzer changed: What|Removed |Added CC||mar...@gmail.com

[Bug 101596] Blender renders black UI elements

https://bugs.freedesktop.org/show_bug.cgi?id=101596 --- Comment #4 from Matias N. Goldberg --- +1 I get this error too. This bug is NOT https://bugs.freedesktop.org/show_bug.cgi?id=97059 which gets fixed by either using DRI2 or selecting Triple Buffer in Blender. This

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

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

[Bug 101596] Blender renders black UI elements

https://bugs.freedesktop.org/show_bug.cgi?id=101596 --- Comment #7 from Matias N. Goldberg --- As I keep reading the code and getting familiar, everything starts making sense: /** * If a shader can be created when we get its source. * This means it has only 1 variant,

Re: [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

Regards Shashank On 7/4/2017 9:26 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote: YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds a drm helper to validate YCBCR420-only mode on a particular connector. This function will

[Bug 101596] Blender renders black UI elements

https://bugs.freedesktop.org/show_bug.cgi?id=101596 --- Comment #5 from Matias N. Goldberg --- Mystery solved: When I click the material button, this function is hit: 1 st_get_fp_variantst_program.c 1326 0x7fbb34c5c595 2 get_color_fp_variant

[PATCH v3 09/16] drm: cirrus: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Signed-off-by: Peter Rosin ---

[PATCH v3 04/16] drm/color-mgmt: move atomic state/commit out from .gamma_set

Handle the atomics directly in the ioctl instead, in preparation for the fb_setcmap helper needing to commit the gamma map for several crtc in one commit. Signed-off-by: Peter Rosin --- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |

[PATCH v3 06/16] drm: amd: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Signed-off-by: Peter Rosin ---

[PATCH v3 03/16] drm/fb-helper: remove drm_fb_helper_save_lut_atomic

drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is now always kept up to date by drm_fb_helper_setcmap. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_fb_helper.c | 17 - 1 file changed, 17 deletions(-) diff --git

[PATCH v3 14/16] drm: radeon: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Signed-off-by: Peter Rosin ---

[PATCH v3 12/16] drm: mgag200: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Signed-off-by: Peter Rosin ---

[PATCH v3 05/16] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get completely obsolete. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_fb_helper.c | 165 +++- 1 file changed, 94 insertions(+), 71 deletions(-) diff --git

[PATCH v3 10/16] drm: gma500: remove dead code and pointless local lut storage

The redundant fb helpers .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Signed-off-by: Peter Rosin --- drivers/gpu/drm/gma500/framebuffer.c |

[PATCH v3 16/16] drm: remove unused and redundant callbacks

Drivers no longer have any need for these callbacks, and there are no users. Zap. Zap-zap-zzzap-p-pp-p. Signed-off-by: Peter Rosin --- include/drm/drm_crtc.h | 8 include/drm/drm_fb_helper.h | 32

[PATCH v3 00/16] improve the fb_setcmap helper

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than

[PATCH v3 13/16] drm: nouveau: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Signed-off-by: Peter Rosin ---

[PATCH v3 08/16] drm: ast: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Signed-off-by: Peter Rosin --- drivers/gpu/drm/ast/ast_drv.h |

  1   2   >