[PATCH 15/15] 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 V5: Added r-b from

[PATCH 14/15] drm/i915: set colorspace for YCBCR420 outputs

When output colorspace is YCBCR420, we have to load the corresponding colorspace in AVI infoframe. This patch fills the colorspace of AVI infoframe as per the output mode. V2: Rebase V3: Rebase V4: Rebase V5: Added r-b from Ander V6: Checking RGB/YCBCR420 output only (Ville) Cc: Ville Syrjala

[PATCH 13/15] drm/i915: prepare csc unit for YCBCR420 output

To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. 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, which uses recommended bspec values to

[PATCH 12/15] drm/i915: prepare pipe for YCBCR420 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 07/15] 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 10/15] drm/i915: add config function for YCBCR420 outputs

This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420 output, else continue with RGB output mode. It checks if the mode is YCBCR420 and source can support this output then it marks the

[PATCH 06/15] 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. - A bool variable (ycbcr_420_allowed) in the drm

[PATCH 11/15] 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 08/15] drm: set output colorspace in AVI infoframe

A source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. This patch adds a function to add the output colorspace information in the AVI infoframes. V2: Rebase V3: Rebase V4: Rebase V5: Rebase V6: Made patch independent of HDMI

[PATCH 04/15] drm/edid: cleanup patch for CEA extended-tag macro

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 05/15] drm/edid: parse YCBCR420 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 09/15] drm: add helper functions for YCBCR420 handling

This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 also mode. V2: Added YCBCR functions as helpers in DRM layer, instead of keeping it in I915 layer. V3: Added handling

[PATCH 02/15] 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 00/15] YCBCR 4:2:0 handling in DRM layer

Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, which is currently supported on HDMI 2.0 sources/sinks. Due to lower chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half the pixel clock than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA 4K@60, RGB

[PATCH 01/15] drm: handle HDMI 2.0 VICs in 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 03/15] 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

[PATCH] drm/radeon: Fix eDP for single-display iMac10,1 (v2)

The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 07/07/17 10:34 AM, Michel Dänzer wrote: > On 07/07/17 12:04 AM, Keith Packard wrote: >> Michel Dänzer writes: >> @@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev) if (!dev_priv) return -EINVAL; + if

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 07/07/17 12:04 AM, Keith Packard wrote: > Michel Dänzer writes: > >>> @@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev) >>> if (!dev_priv) >>> return -EINVAL; >>> >>> + if (dev->driver->get_vblank_counter) >>> +

[Bug 101712] CPU lockup after ring 0 stalled

https://bugs.freedesktop.org/show_bug.cgi?id=101712 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi

[radeon-alex:amd-staging-drm-next 552/612] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1802:2-7: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 69133a7dd030d061a2c7a0334441cfe657e4b53f commit: 22cdbf5cc45dba5c8f7be3277cafeee6bcf67978 [552/612] drm/amd/display: Universal cursor plane hook-up. coccinelle warnings: (new ones prefixed by >>) >>

[PATCH] drm/amd/display: fix ifnullfree.cocci warnings

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1802:2-7: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values.

Re: [PATCH] drm/rockchip: fix NULL check on devm_kzalloc() return value

On 2017年07月07日 05:58, Gustavo A. R. Silva wrote: The right variable to check here is port, not dp. This issue was detected using Coccinelle and the following semantic patch: @@ expression x; identifier fld; @@ * x = devm_kzalloc(...); ... when != x == NULL x->fld Signed-off-by: Gustavo

[PATCH v4 13/14] drm: stm: remove dead code and pointless local lut storage

The redundant fb helper .load_lut is no longer used, and can not work right without also providing the fb helpers .gamma_set and .gamma_get thus rendering the code in this driver suspect. Just remove the dead code. Signed-off-by: Peter Rosin --- drivers/gpu/drm/stm/ltdc.c | 12

Re: [PATCH v2] drm/panel: Add driver for Seiko 43WVF1G panel

Rob, 2017-06-30 17:46 GMT-03:00 Marco Franchi : > Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) > TFT with Touch-Panel. > > Datasheet available at: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf > > Seiko 43WVF1G panel has two power supplies:

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On Thu, Jul 06, 2017 at 12:56:43PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 06, 2017 at 12:45:55PM +0100, Russell King - ARM Linux wrote: > > Well, from what I can see in 4.12, the cec-notifier stuff is rather > > broken (tda998x has stopped working as its stuck with a physical > >

[PATCH v4 04/14] 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 v4 05/14] drm: armada: remove dead empty functions

The redundant fb helpers .gamma_set and .gamma_get are no longer used. Remove the dead code. Signed-off-by: Peter Rosin --- drivers/gpu/drm/armada/armada_crtc.c | 10 -- drivers/gpu/drm/armada/armada_crtc.h | 2 -- drivers/gpu/drm/armada/armada_fbdev.c | 2 -- 3

[PATCH v4 01/14] drm/atomic: export drm_atomic_replace_property_blob

While at it, add some words in the kernel-doc about the 'replaced' arg and remove a faulty kernel-doc comment on the return value. Also remove a redundant return statement. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_atomic.c | 17 +

[PATCH v4 14/14] 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 v4 07/14] 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 v4 10/14] 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 v4 00/14] 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

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On Thu, Jul 06, 2017 at 01:29:54PM +0200, Neil Armstrong wrote: > On 07/06/2017 01:05 PM, Russell King - ARM Linux wrote: > > On Thu, Jul 06, 2017 at 12:33:06PM +0200, Neil Armstrong wrote: > >> From: Russell King > >> > >> Add CEC notifier support to the HDMI bridge

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On Thu, Jul 06, 2017 at 12:45:55PM +0100, Russell King - ARM Linux wrote: > Well, from what I can see in 4.12, the cec-notifier stuff is rather > broken (tda998x has stopped working as its stuck with a physical > address of f.f.f.f) so I think the whole thing is rather moot right > now. I don't

printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

-love.SAKURA.ne.jp/tmp/serial-20170706.txt.xz : [ 779.494100] Mem-Info: [ 779.495493] active_anon:846948 inactive_anon:5416 isolated_anon:0 [ 779.495493] active_file:33 inactive_file:13 isolated_file:47 [ 779.495493] unevictable:0 dirty:11

[PATCH v4 09/14] drm: i915: remove dead code and pointless local lut storage

The driver stores lut values from the fbdev interface, and is able to give them back, but does not appear to do anything with these lut values. The generic fb helpers have replaced this function, and may even have made the driver work for the C8 mode from the fbdev interface. But that is untested.

[PATCH] drm/rockchip: fix NULL check on devm_kzalloc() return value

The right variable to check here is port, not dp. This issue was detected using Coccinelle and the following semantic patch: @@ expression x; identifier fld; @@ * x = devm_kzalloc(...); ... when != x == NULL x->fld Signed-off-by: Gustavo A. R. Silva ---

[PATCH v4 03/14] drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths

The legacy path implements setcmap in terms of crtc .gamma_set. The atomic path implements setcmap by directly updating the crtc gamma_lut property. This has a couple of benefits: - it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get completely obsolete. They are now unused

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On Thu, Jul 06, 2017 at 01:55:58PM +0200, Neil Armstrong wrote: > On 07/06/2017 01:45 PM, Russell King - ARM Linux wrote: > > Well, from what I can see in 4.12, the cec-notifier stuff is rather > > broken (tda998x has stopped working as its stuck with a physical > > address of f.f.f.f) so I think

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On Thu, Jul 06, 2017 at 02:38:41PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 06, 2017 at 12:56:43PM +0100, Russell King - ARM Linux wrote: > > On Thu, Jul 06, 2017 at 12:45:55PM +0100, Russell King - ARM Linux wrote: > > > Well, from what I can see in 4.12, the cec-notifier stuff is

[PATCH v4 06/14] 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 |

[PATCH v4 02/14] drm/atomic-helper: update lut props directly in ..._legacy_gamma_set

Do not waste cycles looking up the property id when we have the actual property already. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_atomic_helper.c | 23 --- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

Hi Neil, On 06-07-2017 11:33, Neil Armstrong wrote: > From: Russell King > > Add CEC notifier support to the HDMI bridge driver, so that the CEC > part of the IP can receive its physical address. > > Tested-by: Neil Armstrong > Acked-by:

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

On 2017-07-06 07:55, Daniel Vetter wrote: > On Wed, Jul 5, 2017 at 7:50 PM, Peter Rosin wrote: +retry: +ret = drm_modeset_lock_all_ctx(dev, ); >>> >>> With atomic you don't need to grab locks, this is done behind the scenes >>> (as long as you handle the

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On Thu, Jul 06, 2017 at 12:33:06PM +0200, Neil Armstrong wrote: > From: Russell King > > Add CEC notifier support to the HDMI bridge driver, so that the CEC > part of the IP can receive its physical address. > > Tested-by: Neil Armstrong >

[PATCH v4 11/14] 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 v4 12/14] 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 v4 08/14] 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 |

[Bug 101712] CPU lockup after ring 0 stalled

https://bugs.freedesktop.org/show_bug.cgi?id=101712 guiscara...@gmail.com changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop

Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

Chrstian, you are probably the best person to ack this, I'd like to get the radv code landed and allow the GL code to get going. Dave. > This adds kernel semaphore support to the command submission > interface in what should be a backwards compatible manner, > it adds a new command submission

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 6, 2017 at 6:27 PM, Keith Packard wrote: > Daniel Vetter writes: > >> I very much like this since the old ioctl really is a rather bad horror >> show. And since it's tied in with ums drivers everything is >> complicated. > > Thanks for your kind

[PATCH 1/6] drm: Add helper to check exporting driver of a DMA-buf

This allows drivers to check if a DMA-buf contains a GEM object and whether it comes from the same driver. It may be from the same or a different device. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/drm_prime.c | 24 include/drm/drmP.h

[PATCH v5 22/22] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore

From: Ville Syrjälä Introduce an rw_semaphore to protect the display commits. All normal commits use down_read() and hence can proceed in parallel, but GPU reset will use down_write() making sure no other commits are in progress when we have to pull the plug on the

[PATCH 18/22] drm: Return the connector from drm_connector_get()

From: Ville Syrjälä Make drm_connector_get() return the connector. This allows the nice pattern of 'foo->connector = drm_connector_get(connector)' Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 3 +--

[PATCH 14/22] drm/arm: s/old_state/old_mali_state/

From: Ville Syrjälä Rename the local 'old_state' variable to 'old_mali_state' to get it out of the way of some cocci refactoring. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/malidp_crtc.c | 10 +- 1 file changed, 5

[PATCH v3 21/22] drm/atomic: Introduce drm_atomic_helper_duplicate_commited_state()

From: Ville Syrjälä For i915 GPU reset handling we'll want to be able to duplicate the state that was last commited to the hardware. For that purpose let's start to track the commited state for each object and provide a way to duplicate the commmited state into a

[PATCH 19/22] drm/i915% Store vma gtt offset in plane state

From: Ville Syrjälä To avoid having to deference plane_state->vma during the commit phase of plane updates, let's store the vma gtt offset (or the bus address when we need it) in the plane state. This is crucial for doing the modeset operations during GPU reset as

[PATCH 20/22] drm/i915: Refactor __intel_atomic_commit_tail()

From: Ville Syrjälä Split intel_atomic_commit_tail() into a lower level function that does the actual commit, and a higher level one that waits for the dependencies and signals the commit as done. We'll reuse the lower level function to perform commits during GPU

[PATCH 17/22] drm/atomic: Fix up the kernel docs for the state duplication functions

From: Ville Syrjälä Coccinelle doesn't fix up the docs for us, so let's do it manually. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 12 +--- include/drm/drm_connector.h | 2 +-

[PATCH 16/22] drm/atomic: Pass old state explicitly to .atomic_duplicate_state()

From: Ville Syrjälä We'll be wanting to duplicate other states besides the one pointed to by crtc->state & co., so pass the duplicated state in explicitly. I wanted to make the old_state const, but that would have results in tons of new warnings because some

[PATCH 12/22] drm/atomic: Make private objs proper objects

From: Ville Syrjälä Make the atomic private object stuff less special by introducing proper base classes for the object and its state. Drivers can embed these in their own appropriate objects, after which these things will work exactly like the plane/crtc/connector

[PATCH 11/22] drm/atomic: Convert private_objs to drm_dynarray

From: Ville Syrjälä state->private_objs grows dynamically, so switch it over to use the new drm_dynarray helper. Cc: Dhinakaran Pandiyan Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c

Re: [PATCH 1/6] drm: Add helper to check exporting driver of a DMA-buf

Am 06.07.2017 um 22:16 schrieb Felix Kuehling: This allows drivers to check if a DMA-buf contains a GEM object and whether it comes from the same driver. It may be from the same or a different device. Signed-off-by: Felix Kuehling I think Daniel/Dave hadmore a

[PATCH 15/22] drm/mediatek: s/old_state/old_mtk_state/

From: Ville Syrjälä Rename the local 'old_state' variable to 'old_mtk_state' to get it out of the way of some cocci refactoring. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 4 ++-- 1 file changed, 2

[PATCH 13/22] drm/atomic: Pass old state to __drm_atomic_helper_crtc_duplicate_state() & co. explicitly

From: Ville Syrjälä We'll be wanting to duplicate other states besides the one pointed to by crtc->state & co., so pass the duplicated state in explicitly. @r@ identifier F =~ "^__drm_atomic_helper_.*_duplicate_state$"; identifier O, S; type T, TS; @@ F(T O, TS *S

[PATCH 09/22] drm/atomic: Convert state->connectors to drm_dynarray

From: Ville Syrjälä state->connectors[] can grows dynamically, so we can switch over to using the new drm_dynarray. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 49 +++--

[PATCH 10/22] drm/atomic: Remove pointless private object NULL state check

From: Ville Syrjälä We will never add private objects with a NULL state into the atomic state, hence checking for that is pointless. Cc: Dhinakaran Pandiyan Reviewed-by: Daniel Vetter Signed-off-by: Ville

[PATCH 08/22] drm: Add drm_dynarray

From: Ville Syrjälä Add a small helper that gives us dynamically growing arrays. We have a couple hand rolled implementations of this in the atomic code, which we can unify to use a common implementation. Signed-off-by: Ville Syrjälä

[PATCH 07/22] drm/i915: Eliminate crtc->state usage from intel_atomic_commit_tail and .crtc_update()

From: Ville Syrjälä We already have the correct new crtc state so just use that instead of crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH 06/22] drm/i915: Eliminate crtc->state usage from intel_update_pipe_config()

From: Ville Syrjälä Pass the correct new crtc state to intel_update_pipe_config() instead of using crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 19 +-- 1 file changed, 9

[PATCH v2 00/22] drm/i915: Fix pre-g4x GPU reset, again (v2)

From: Ville Syrjälä OK, so here's the full version of my rw_semaphore GPU vs. display reset fix. The only issue I'm aware of is that SKL watermark code still uses obj->state and thus I have no clue what would happen if one tries to run this on SKL. Untangling that

[PATCH 04/22] drm/i915: Pass proper old/new states to intel_plane_atomic_check_with_state()

From: Ville Syrjälä Eliminate plane->state and crtc->state usage from intel_plane_atomic_check_with_state() and its callers. Instead pass the proper states in or dig them up from the top level atomic state. Note that intel_plane_atomic_check_with_state() itself

[PATCH 02/22] drm/i915: Pass the crtc state explicitly to intel_pipe_update_start/end()

From: Ville Syrjälä Pass the appropriate new crtc state explicitly to intel_pipe_update_start/end() instead of of mucking around with crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 18

[PATCH 05/22] drm/i915: Eliminate obj->state usage from pre/post plane update

From: Ville Syrjälä Dig up the appropriate new crtc and plane states from the top level atomic state in intel_pre_plane_update() and intel_post_plane_update(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c |

[PATCH 03/22] drm/i915: Eliminate obj->state usage in g4x/vlv/chv wm computation

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/intel_drv.h | 8 drivers/gpu/drm/i915/intel_pm.c | 30 +++--- 3 files

[PATCH 01/22] drm/i915: Pass the new crtc state to color management code

From: Ville Syrjälä In an effort to eliminate the obj->state usage let's pass on the new crtc state pointer (which we already have!) to the color management code. Signed-off-by: Ville Syrjälä ---

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > With the disable_immediate thing we only wait until the next vblank > before disabling the irq again. Ok, still sounds like we'll be doing fine if the application does a get immediately followed by a queue event. At least most of the time.

[PATCH v2 3/4] drm/i915: Call uncore_suspend before platform suspend handlers

Quoting Ville: "the forcewake timer might still be active until the uncore suspend, and having active forcewakes while we've already told the GT wake stuff to stop acting normally doesn't seem quite right to me." Reported-by: Ville Syrjälä Suggested-by: Imre Deak

[PATCH v2 2/4] drm/i915: Re-register PMIC bus access notifier on runtime resume

intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier

[PATCH v2 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

intel_uncore_forcewake_reset() does forcewake puts and gets as such we need to make sure that no-one tries to access the PUNIT->PMIC bus (on systems where this bus is shared) while it runs, otherwise bad things happen. Normally this is taken care of by the i915_pmic_bus_access_notifier() which

[PATCH v2 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(_priv->pm.wakeref_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 #10 from Alex Deucher (alexdeuc...@gmail.com) --- Can you get a log with symbols? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 11:22:43AM -0700, Keith Packard wrote: > Ville Syrjälä writes: > > > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > > where we can avoid doing the full update more than once if we enable > > the interrupt already

[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 #9 from Olaf H B (o...@seldiame.net) --- Created attachment 257391 --> https://bugzilla.kernel.org/attachment.cgi?id=257391=edit kern.log -- 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 #8 from Olaf H B (o...@seldiame.net) --- (In reply to Michel Dänzer from comment #6) > Is this a regression from older kernel versions? If yes, can you bisect? I don't think this is a regression because I had similar issues with

[Bug 99859] Glamor Crashes on big endian Hardware

https://bugs.freedesktop.org/show_bug.cgi?id=99859 --- Comment #22 from intermedi...@hotmail.com --- last mesa xorg log just to report. different error. with last mesa dev OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.0-devel (git-f78aa2c986) [

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > where we can avoid doing the full update more than once if we enable > the interrupt already during the query. Don't we still wait 5 seconds before disabling vblank? In

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 09:28:40AM -0700, Keith Packard wrote: > Ville Syrjälä writes: > > > Maybe, or maybe we want to turn the interrupt on in that case? That's > > what the old ioctl does. > > That's what I suggested in my reply to Daniel's review. Even if we

[Bug 99292] GPU hang in High Fidelity

https://bugs.freedesktop.org/show_bug.cgi?id=99292 --- Comment #5 from Christoph Haag --- I don't know if it's still the same problem but now it always happens *very* quickly after starting the app. Here's a fresh api trace:

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > Maybe, or maybe we want to turn the interrupt on in that case? That's > what the old ioctl does. That's what I suggested in my reply to Daniel's review. Even if we add the accurate function, we'll still need the interrupt-enable case as a

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Daniel Vetter writes: > I very much like this since the old ioctl really is a rather bad horror > show. And since it's tied in with ums drivers everything is > complicated. Thanks for your kind words. > I started a discussion a while back whether these should be restricted to

[Bug 194761] amdgpu driver breaks on Oland (SI)

https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #71 from Alexander Tsoy (alexan...@tsoy.me) --- (In reply to Alexander Tsoy from comment #70) > For me P4_8x16 config fixed this issue. > > $ sudo dmesg | egrep 'RAM width|OLAND' > [1.670667] [drm] initializing kernel modesetting

Re: [PATCH 2/3] drm: Reorganize drm_pending_event to support future event types

Daniel Vetter writes: > A few nits below, but looks good otherwise. Thanks. >> static struct drm_pending_vblank_event *create_vblank_event( >> -struct drm_device *dev, uint64_t user_data) >> +struct drm_device *dev, struct drm_crtc *crtc, uint64_t >>

[Bug 194761] amdgpu driver breaks on Oland (SI)

https://bugzilla.kernel.org/show_bug.cgi?id=194761 Alexander Tsoy (alexan...@tsoy.me) changed: What|Removed |Added CC||alexan...@tsoy.me

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

https://bugs.freedesktop.org/show_bug.cgi?id=99801 --- Comment #13 from Matthew Treinish --- I was wondering if there was any update on this? I'm still seeing the same issue on a 4.11.7 kernel. I'm willing to test out any patches or provide any additional debug info that is

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > BTW, this got me thinking that we should probably treat > _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating > vblwait->request.sequence. Otherwise there could theoretically (though > unlikely) be an infinite loop: I was thinking

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > Subtle breakage here: vblwait->request.sequence must still get updated > for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal. Thanks for finding this. I think it might be better to just not modify the request.type field instead, so that

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Daniel Vetter writes: > Extending the reported/sw vblank counter to u64 makes sense imo, but do we > have to extend the driver interfaces too? If there's no 64 bit hw vblank > currently I think I'd be good to postpone that part, simply because I'm > too lazy to audit all the

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

On 07/05/2017 11:28 AM, Andrzej Hajda wrote: > On 04.07.2017 18:30, Philippe CORNU wrote: >> 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

  1   2   >