Re: [Intel-gfx] [PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put

On Wed, Jan 04, 2017 at 03:26:48PM -0500, Alex Deucher wrote: > On Wed, Jan 4, 2017 at 11:11 AM, Daniel Vetter wrote: > > On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote: > >> I was lazy, rectify that! Also align with drm_atomic_state_get/put for > >> ocd. > >> > >>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Header cleanup for intel_display

== Series Details == Series: drm/i915: Header cleanup for intel_display URL : https://patchwork.freedesktop.org/series/17526/ State : success == Summary == Series 17526v1 drm/i915: Header cleanup for intel_display https://patchwork.freedesktop.org/api/1.0/series/17526/revisions/1/mbox/

[Intel-gfx] [PATCH] drm/i915: Header cleanup for intel_display

Remove reference to drm/drm_edid.h and drm/drmP.h as these are no longer required. Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/intel_display.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add render decompression support

On 17-01-04 20:42:32, Ville Syrjälä 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 of the color control surfae (CCS) which

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Do not reset detect_done flag in intel_dp_detect

On Thu, 2016-12-29 at 23:14 -0800, Dhinakaran Pandiyan wrote: bump for review. -DK > From: "Navare, Manasi D" > > The detect_done flag was introduced in the 'commit 7d23e3c37bb3 > ("drm/i915: Cleaning up intel_dp_hpd_pulse")' in order to avoid multiple > detects

Re: [Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

On Wed, 2017-01-04 at 19:20 +, Pandiyan, Dhinakaran wrote: > On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote: > > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote: > > > Link bandwidth is shared between multiple display streams in DP MST > > > configurations. The DP

Re: [Intel-gfx] [PATCH 1/9] drm: Add mode_config .get_format_info() hook

On 17-01-04 20:42:24, Ville Syrjälä wrote: From: Ville Syrjälä Allow drivers to return a custom drm_format_info structure for special fb layouts. We'll use this for the compression control surface in i915. v2: Fix drm_get_format_info() kernel doc (Laurent)

[Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

Until now, it seems we've been erroneously enabling limited color ranges for the vast majority of DisplayPort monitors. I noticed this after writing a frame dump comparison test for the Chamelium and noticing that every i915 device I had was failing, while amdgpu machines were fine:

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/usb/Kconfig:39:error: recursive dependency detected! drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH drivers/input/mouse/Kconfig:187:symbol

Re: [Intel-gfx] [PATCH 02/10] drm/i915/psr: program vsc header for psr2

On Mon, Jan 02, 2017 at 05:00:55PM +0530, vathsala nagaraju wrote: > Function hsw_psr_setup handles vsc header setup for psr1 and > skl_psr_setup_vsc handles vsc header setup for psr2. > > Setup VSC header in function skl_psr_setup_vsc for psr2 support, > as per edp 1.4 spec, table 6-11:VSC SDP

[Intel-gfx] [drm-tip:drm-tip 440/460] drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!

tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: ea0500897bf72bbbf6eca6e695c9d49289dfc768 commit: a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8 [440/460] drm: nouveau: fix build when LEDS_CLASS=m config: um-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0

Re: [Intel-gfx] [PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put

On Wed, Jan 4, 2017 at 11:11 AM, Daniel Vetter wrote: > On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote: >> I was lazy, rectify that! Also align with drm_atomic_state_get/put for >> ocd. >> >> v2: Git add helps. >> >> Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

On Wed, Jan 04, 2017 at 03:36:16PM +, Tvrtko Ursulin wrote: > You beat me to solving this interesting bug. :) With the > comments/commit slightly improved: CI chose to ignore this, so sent the improved comments to trybot: https://patchwork.freedesktop.org/series/17506/ Thanks, -Chris --

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: SKL+ render decompression support

== Series Details == Series: drm/i915: SKL+ render decompression support URL : https://patchwork.freedesktop.org/series/17507/ State : success == Summary == Series 17507v1 drm/i915: SKL+ render decompression support https://patchwork.freedesktop.org/api/1.0/series/17507/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote: > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote: > > Link bandwidth is shared between multiple display streams in DP MST > > configurations. The DP MST topology manager structure maintains the shared > > link bandwidth

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: add fourcc codes for 16bit R and RG (rev3)

== Series Details == Series: drm: add fourcc codes for 16bit R and RG (rev3) URL : https://patchwork.freedesktop.org/series/17471/ State : success == Summary == Series 17471v3 drm: add fourcc codes for 16bit R and RG https://patchwork.freedesktop.org/api/1.0/series/17471/revisions/3/mbox/

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add render decompression support

Em Qua, 2017-01-04 às 20:42 +0200, ville.syrj...@linux.intel.com escreveu: > 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 of

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

Op 04-01-17 om 17:19 schreef Chris Wilson: > On Wed, Jan 04, 2017 at 06:06:42PM +0200, Ville Syrjälä wrote: >> On Wed, Jan 04, 2017 at 04:00:49PM +, Chris Wilson wrote: >>> If we are restoring the same plane_state, the old_plane_state will not >>> be unpinned until after the swap. So

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add fourcc codes for 16bit R and RG (rev2)

== Series Details == Series: drm: add fourcc codes for 16bit R and RG (rev2) URL : https://patchwork.freedesktop.org/series/17471/ State : failure == Summary == Series 17471v2 drm: add fourcc codes for 16bit R and RG https://patchwork.freedesktop.org/api/1.0/series/17471/revisions/2/mbox/

[Intel-gfx] [PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS

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 of the color control surfae (CCS) which describes which parts of the main surface are

[Intel-gfx] [PATCH 4/9] drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane

From: Ville Syrjälä To make life easier let's allow skl_plane_stride() to be called for the AUX surface even when there is no AUX surface. Avoids special cases in the callers. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 7/9] drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages

From: Ville Syrjälä DRM_UT_CORE generates way too much noise usually, so having the framebuffer init failures use DRM_UT_CORE is a pain when trying to find out the reason why you failed in creating a framebuffer. Let's use DRM_UT_KMS for these debug messages

[Intel-gfx] [PATCH 9/9] drm/i915: Add render decompression support

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 of the color control surfae (CCS) which describes which parts of the main surface are

[Intel-gfx] [PATCH 6/9] drm/i915: Pass the correct plane index to _intel_compute_tile_offset()

From: Ville Syrjälä intel_fill_fb_info() should pass the correct plane index to _intel_compute_tile_offset() once we start to care about the AUX surface. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 2 +-

[Intel-gfx] [PATCH 5/9] drm/i915: Fix Yf tile width

From: Ville Syrjälä Based on empirical evidence the display engine (at least) always treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions change based on the pixel format. Let's adjust our code to match the hardware. Signed-off-by: Ville

[Intel-gfx] [PATCH 3/9] drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()

From: Ville Syrjälä Let's try to keep the alignment requirements in one place, and so towards that end let's move the AUX_DIST alignment handling into intel_surf_alignment() alongside the main surface alignment stuff. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 2/9] drm/i915: Plumb drm_framebuffer into more places

From: Ville Syrjälä Now that framebuffers can be used even before calling drm_framebuffer_init() we can start to plumb them into more places, instead of passing individual pieces for fb metadata. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 1/9] drm: Add mode_config .get_format_info() hook

From: Ville Syrjälä Allow drivers to return a custom drm_format_info structure for special fb layouts. We'll use this for the compression control surface in i915. v2: Fix drm_get_format_info() kernel doc (Laurent) Don't pass 'dev' to the new hook (Laurent)

[Intel-gfx] [PATCH 0/9] drm/i915: SKL+ render decompression support

From: Ville Syrjälä This series enables the SKL+ display engine render decompression support. Some bits and pieces of the i915 code are based on work from various people, but I just put my name on it since it would be hard to figure out which parts came from where.

[Intel-gfx] [PATCH v6] drm: add fourcc codes for 16bit R and RG

From: Rainer Hochecker This adds fourcc codes for 16bit planes required for DRM buffer export to mesa. Signed-off-by: Rainer Hochecker --- include/uapi/drm/drm_fourcc.h | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [Intel-gfx] [PATCH v5] drm: add fourcc codes for 16bit R and RG

On Wed, Jan 04, 2017 at 07:24:09PM +0100, Rainer Hochecker wrote: > From: Rainer Hochecker > > Thanks for bearing with me. My ml skills have greatly improved now :) > > v5 of patch: > > This adds fourcc codes for 16bit planes required for DRM buffer > export to mesa. >

[Intel-gfx] [PATCH v5] drm: add fourcc codes for 16bit R and RG

From: Rainer Hochecker Thanks for bearing with me. My ml skills have greatly improved now :) v5 of patch: This adds fourcc codes for 16bit planes required for DRM buffer export to mesa. Signed-off-by: Rainer Hochecker ---

Re: [Intel-gfx] [PATCH v4] drm: add fourcc codes for 16bit R and RG

On Wednesday, 2017-01-04 14:50:02 +0100, Rainer Hochecker wrote: > From: Rainer Hochecker > > Signed-off-by: Rainer Hochecker > --- > include/uapi/drm/drm_fourcc.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git

[Intel-gfx] ✗ Fi.CI.BAT: warning for HuC Loading Patches

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/17499/ State : warning == Summary == Series 17499v1 HuC Loading Patches https://patchwork.freedesktop.org/api/1.0/series/17499/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup

Re: [Intel-gfx] [PATCH i-g-t v2] igt_core: add igt_constructor

On Wed, Jan 04, 2017 at 03:20:49PM -0200, Paulo Zanoni wrote: > Em Qua, 2016-12-21 às 15:50 -0500, Lyude escreveu: > > This is a simple macro for executing a block of code at the beginning > > of > > intel-gpu-tools, before any tests have been ran. Useful for > > initialization of global resources

Re: [Intel-gfx] [PATCH i-g-t v2] igt_core: add igt_constructor

Em Qua, 2016-12-21 às 15:50 -0500, Lyude escreveu: > This is a simple macro for executing a block of code at the beginning > of > intel-gpu-tools, before any tests have been ran. Useful for > initialization of global resources used in IGT libraries. IGT doesn't compile anymore here. Reverting

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

Op 04-01-17 om 16:47 schreef Ville Syrjälä: > On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote: >> On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote: >>> On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote: From: Chris Wilson

[Intel-gfx] [PULL] drm-misc-fixes

Hi Dave, One small bugfix to the atomic helpers from Laurent. Haz cc: stable. Cheers, Daniel The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88: Linux 4.10-rc2 (2017-01-01 14:31:53 -0800) are available in the git repository at:

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

On Wed, Jan 04, 2017 at 06:06:42PM +0200, Ville Syrjälä wrote: > On Wed, Jan 04, 2017 at 04:00:49PM +, Chris Wilson wrote: > > If we are restoring the same plane_state, the old_plane_state will not > > be unpinned until after the swap. So prepare_fb will return the > > duplicate VMA with

Re: [Intel-gfx] [PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put

On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote: > I was lazy, rectify that! Also align with drm_atomic_state_get/put for > ocd. > > v2: Git add helps. > > Signed-off-by: Daniel Vetter Anyone feel like acking this, pretty please? ;-) -Daniel > --- >

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

On Wed, Jan 04, 2017 at 04:00:49PM +, Chris Wilson wrote: > On Wed, Jan 04, 2017 at 05:47:50PM +0200, Ville Syrjälä wrote: > > On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote: > > > On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote: > > > > On Wed, Jan 04, 2017 at

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

On Wed, Jan 04, 2017 at 05:47:50PM +0200, Ville Syrjälä wrote: > On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote: > > On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote: > > > On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote: > > > > From: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

On 04/01/2017 15:45, Chris Wilson wrote: On Wed, Jan 04, 2017 at 03:36:16PM +, Tvrtko Ursulin wrote: On 04/01/2017 14:51, Chris Wilson wrote: During the fence registers are clobbered by a GPU reset. Hence if During the reset I suppose, although it would sound still a bit redundant. So

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()

Hi Chris, Thanks for your patches! On 4 January 2017 at 20:40, Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote: >> As the fence->status is an optional field that may be set before >> dma_fence_signal() is called to convey that the fence

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote: > On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote: > > On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote: > > > From: Chris Wilson > > > > > > With atomic plane states we are

Re: [Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

On Wed, Jan 04, 2017 at 03:36:16PM +, Tvrtko Ursulin wrote: > > On 04/01/2017 14:51, Chris Wilson wrote: > >During the fence registers are clobbered by a GPU reset. Hence if > > During the reset I suppose, although it would sound still a bit > redundant. So maybe "Since GPU reset clobbers

Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix outdated comment.

On Wed, Jan 04, 2017 at 12:34:00PM +0100, Maarten Lankhorst wrote: > Op 04-01-17 om 12:28 schreef Daniel Vetter: > > On Wed, Jan 04, 2017 at 11:22:54AM +, Chris Wilson wrote: > >> On Wed, Jan 04, 2017 at 12:15:55PM +0100, Maarten Lankhorst wrote: > >>> Op 15-12-16 om 16:19 schreef Daniel

Re: [Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

On 04/01/2017 14:51, Chris Wilson wrote: During the fence registers are clobbered by a GPU reset. Hence if During the reset I suppose, although it would sound still a bit redundant. So maybe "Since GPU reset clobbers the fence registers, if there is concurrent..." there is concurrent

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] dma-fence: Clear fence->status during dma_fence_init()

== Series Details == Series: series starting with [1/3] dma-fence: Clear fence->status during dma_fence_init() URL : https://patchwork.freedesktop.org/series/17493/ State : warning == Summary == Series 17493v1 Series without cover letter

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Tue, Jan 03, 2017 at 06:59:11PM +, Srivatsa, Anusha wrote: > > > >-Original Message- > >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > >Srivatsa, Anusha > >Sent: Monday, January 2, 2017 4:09 PM > >To: Wajdeczko, Michal

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote: > On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote: > > From: Chris Wilson > > > > With atomic plane states we are able to track an allocation right from > > preparation, during use and

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()

On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote: > As the fence->status is an optional field that may be set before > dma_fence_signal() is called to convey that the fence completed with an > error, we have to ensure that it is always set to zero on initialisation > so that the

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

On Wed, Jan 04, 2017 at 06:55:49AM -0800, Anusha Srivatsa wrote: > From: Peter Antoine > > HuC firmware css header has almost exactly same definition as GuC > firmware except for the sw_version. Also, add a new member fw_type > into intel_uc_fw to indicate what kind of

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote: > From: Chris Wilson > > With atomic plane states we are able to track an allocation right from > preparation, during use and through to the final free after being > swapped out for a new plane. We can

[Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

From: Peter Antoine The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

From: Peter Antoine This patch will allow for getparams to return the status of the HuC. As the HuC has to be validated by the GuC this patch uses the validated status to show when the HuC is loaded and ready for use. You cannot use the loaded status as with the GuC as

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

This patch adds the HuC Loading for the BXT by using the updated file construction. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename BXT_FW_MAJOR to BXT_HUC_FW_ v6: rebased. v7: rebased. Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

From: Peter Antoine Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. v8: rebased. v9: rebased. v10: rebased. v11: rebased on top of drm-tip v12: rebased. v13: rebased. v14: rebased. Tested-by: Xiang

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

This patch adds the support to load HuC on KBL Version 2.0 v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_ v6: rebased. Remove old checks. v7: rebased. Cc: Tvrtko Ursulin Signed-off-by: Anusha Srivatsa

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2: rebased on-top of drm-intel-nightly. removed if(HAS_GUC()) before the guc call.

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

From: Peter Antoine HuC firmware css header has almost exactly same definition as GuC firmware except for the sw_version. Also, add a new member fw_type into intel_uc_fw to indicate what kind of fw it is. So, the loader will pull right sw_version from header. v2:

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

These patches add HuC loading support. The driver builds a frame level workload which is stored in the graphics memory. This workload is presented to HuC for processing. The driver, therefore should first determine if the HuC is enabled and also read the huC athentication status bit to determine

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

From: Peter Antoine Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

[Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

During the fence registers are clobbered by a GPU reset. Hence if there is concurrent user access to a fenced region via a GTT mmaping, the access will not be fenced during the reset (until we restore the fences afterwards). In order to prevent invalid access during the reset, before we clobber

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Track pinned vma in intel_plane_state

== Series Details == Series: drm/i915: Track pinned vma in intel_plane_state URL : https://patchwork.freedesktop.org/series/17490/ State : warning == Summary == Series 17490v1 drm/i915: Track pinned vma in intel_plane_state

[Intel-gfx] [PATCH 3/3] dma-fence: Introduce drm_fence_set_error() helper

The dma_fence.error field (formerly known as dma_fence.status) is an optional field that may be set by drivers before calling dma_fence_signal(). The field can be used to indicate that the fence was completed in err rather than with success, and is visible to other consumers of the fence and to

[Intel-gfx] [PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()

As the fence->status is an optional field that may be set before dma_fence_signal() is called to convey that the fence completed with an error, we have to ensure that it is always set to zero on initialisation so that the typical use (i.e. unset) always flags a successful completion.

[Intel-gfx] [PATCH 2/3] dma-fence: Wrap querying the fence->status

The fence->status is an optional field that is only valid once the fence has been signaled. (Driver may fill the fence->status with an error code prior to calling dma_fence_signal().) Given the restriction upon its validity, wrap querying of the fence->status into a helper dma_fence_get_status().

[Intel-gfx] ✗ Fi.CI.BAT: failure for HuC Loading Patches

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/17489/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/gvt.o CC [M] drivers/gpu/drm/i915/gvt/aperture_gm.o CC [M] drivers/gpu/drm/i915/gvt/vgpu.o CC [M]

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

>-Original Message- >From: Wajdeczko, Michal >Sent: Wednesday, January 4, 2017 5:59 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Hiler, Arkadiusz > >Subject: Re: [PATCH 1/8] drm/i915/guc: Make the GuC fw loading

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On Wed, Jan 04, 2017 at 05:27:23AM -0800, Anusha Srivatsa wrote: > From: Peter Antoine > > Rename some of the GuC fw loading code to make them more general. We > will utilise them for HuC loading as well. > s/intel_guc_fw/intel_uc_fw/g >

[Intel-gfx] [PATCH v4] drm: add fourcc codes for 16bit R and RG

From: Rainer Hochecker Signed-off-by: Rainer Hochecker --- include/uapi/drm/drm_fourcc.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index a5890bf..4d65fb6 100644 ---

[Intel-gfx] [PATCH v3] drm: add fourcc codes for 16bit R and RG

From: Rainer Hochecker This adds fourcc codes for 16bit planes required for DRM buffer export to mesa. Signed-off-by: Rainer Hochecker --- include/uapi/drm/drm_fourcc.h | 7 +++ 1 file changed, 7 insertions(+) diff --git

[Intel-gfx] [drm-intel:drm-intel-nightly 440/455] warning: (DRM_NOUVEAU && ..) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && ..)

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 3ff9912451fd6840732ac0184f0561c9e6c4107f commit: a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8 [440/455] drm: nouveau: fix build when LEDS_CLASS=m config: x86_64-randconfig-x016-201701 (attached as .config) compiler: gcc-6

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2: rebased on-top of drm-intel-nightly. removed if(HAS_GUC()) before the guc call.

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

This patch adds the support to load HuC on KBL Version 2.0 v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_ v6: rebased. Remove old checks. v7: rebased. Cc: Tvrtko Ursulin Signed-off-by: Anusha Srivatsa

[Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

From: Chris Wilson With atomic plane states we are able to track an allocation right from preparation, during use and through to the final free after being swapped out for a new plane. We can couple the VMA we pin for the framebuffer (and its rotation) to this lifetime

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

These patches add HuC loading support. The driver builds a frame level workload which is stored in the graphics memory. This workload is presented to HuC for processing. The driver, therefore should first determine if the HuC is enabled and also read the huC athentication status bit to determine

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

From: Peter Antoine This patch will allow for getparams to return the status of the HuC. As the HuC has to be validated by the GuC this patch uses the validated status to show when the HuC is loaded and ready for use. You cannot use the loaded status as with the GuC as

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

This patch adds the HuC Loading for the BXT by using the updated file construction. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename BXT_FW_MAJOR to BXT_HUC_FW_ v6: rebased. v7: rebased. Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

From: Peter Antoine The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

From: Peter Antoine HuC firmware css header has almost exactly same definition as GuC firmware except for the sw_version. Also, add a new member fw_type into intel_uc_fw to indicate what kind of fw it is. So, the loader will pull right sw_version from header. v2:

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

From: Peter Antoine Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

From: Peter Antoine Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. v8: rebased. v9: rebased. v10: rebased. v11: rebased on top of drm-tip v12: rebased. v13: rebased. v14: rebased. Tested-by: Xiang

[Intel-gfx] [PATCH igt] lib: Always unbind the fbcon around igt

The fbcon imposes unpredictable latencies on tests - each drmIoctl has been observed to trigger two 650us calls to console_unlock() as it flushes printk buffer for the DRM_DEBUG around the ioctl. This makes tests such as gem_wait fail as they expect the ioctl to be spent on the operation under

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

On Wed, Jan 04, 2017 at 10:26:49AM +, Chris Wilson wrote: > On Wed, Jan 04, 2017 at 11:18:58AM +0100, Daniel Vetter wrote: > > On Wed, Jan 04, 2017 at 09:43:51AM +, Chris Wilson wrote: > > > On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote: > > > > On Wed, Jan 04, 2017 at

Re: [Intel-gfx] [PATCH] drm/atomic: Fix outdated comment.

On Wed, Jan 04, 2017 at 11:22:54AM +, Chris Wilson wrote: > On Wed, Jan 04, 2017 at 12:15:55PM +0100, Maarten Lankhorst wrote: > > Op 15-12-16 om 16:19 schreef Daniel Vetter: > > > On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote: > > >> drm_atomic_state_put is called

Re: [Intel-gfx] [PATCH] drm/atomic: Fix outdated comment.

On Wed, Jan 04, 2017 at 12:15:55PM +0100, Maarten Lankhorst wrote: > Op 15-12-16 om 16:19 schreef Daniel Vetter: > > On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote: > >> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no > >> different from commit. > >> > >>

[Intel-gfx] [PATCH] drm/atomic: Fix outdated comment.

Op 15-12-16 om 16:19 schreef Daniel Vetter: > On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote: >> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no >> different from commit. >> >> Signed-off-by: Maarten Lankhorst > I think it'd

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

Forgot to CC the list, sorry. On Wed, Jan 4, 2017 at 11:42 AM, Peter Frühberger wrote: > Hi Jani, > thanks for your reply > > On Wed, Jan 4, 2017 at 10:34 AM, Jani Nikula > wrote: > >> On Wed, 04 Jan 2017, Peter Frühberger wrote: >> >

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

On Wed, Jan 04, 2017 at 11:18:58AM +0100, Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 09:43:51AM +, Chris Wilson wrote: > > On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote: > > > On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote: > > > > On Wed, Jan 04, 2017 at

Re: [Intel-gfx] [PATCH v2] drm: add fourcc codes for 16bit R and GR

On Wednesday, 2017-01-04 11:06:09 +0200, Jani Nikula wrote: > On Wed, 04 Jan 2017, Daniel Vetter wrote: > > On Tue, Jan 03, 2017 at 08:02:07PM +0100, Rainer Hochecker wrote: > >> From: Rainer Hochecker > >> > >> Now sent with git send-email: > >> > >>

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

On Wed, Jan 04, 2017 at 09:43:51AM +, Chris Wilson wrote: > On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote: > > On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote: > > > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote: > > > > On Tue, Jan 03, 2017 at

Re: [Intel-gfx] [PATCH 1/2] drm: refernce count event->completion

On Wed, Dec 21, 2016 at 12:08:45PM +0100, Maarten Lankhorst wrote: > Op 21-12-16 om 11:36 schreef Chris Wilson: > > On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote: > >> When writing the generic nonblocking commit code I assumed that > >> through clever lifetime management I can

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote: > > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote: > > > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote: > > > > > > > > On 03/01/2017

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote: > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote: > > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote: > > > > > > On 03/01/2017 11:05, Chris Wilson wrote: > > > > As the fence->status is an optional field

Re: [Intel-gfx] [PATCH 0/6] Introduce DP MST Topology state

On Tue, Jan 03, 2017 at 01:01:45PM -0800, Dhinakaran Pandiyan wrote: > Link bandwidth is shared between multiple display streams in DP MST > configurations. The DP MST topology manager structure maintains the shared > link bandwidth for a primary link directly connected to the GPU. For atomic >

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

On Wed, 04 Jan 2017, Peter Frühberger wrote: > Hi > > On Sun, Nov 6, 2016 at 1:23 AM, Pandiyan, Dhinakaran < > dhinakaran.pandi...@intel.com> wrote: > >> On Sat, 2016-11-05 at 21:40 +0200, Jani Nikula wrote: >> > On Fri, 04 Nov 2016, "Pandiyan, Dhinakaran" < >>

Re: [Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote: > Link bandwidth is shared between multiple display streams in DP MST > configurations. The DP MST topology manager structure maintains the shared > link bandwidth for a primary link directly connected to the GPU. For atomic >

Re: [Intel-gfx] [PATCH 6/6] drm/i915/dp: Track available DP MST vcpi time slots

On Tue, Jan 03, 2017 at 01:01:51PM -0800, Dhinakaran Pandiyan wrote: > Make use of the added MST helpers to find, allocate and release link bw > for atomic modesets. > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_display.c | 39 >

  1   2   >