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

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

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

The 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 if

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

The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-tip. Changed name format and upped version 1.7. v3: changed wait_for_atomic to wait_for v4: rebased. Rename intel_huc_auh() to intel_guc_auth_huc() and place the

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

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: rebased on-top of drm-intel-nightly v3: rebased.

[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 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 on to top drm-tip. Rename BXT_FW_MAJOR to BXT_HUC_FW_ Cc: Micha Wajdeczko Cc: Tvrtko Ursulin

[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 on top of drm-tip. Rename KBL_FW_ to KBL_HUC_FW_ v3: rebased. Remove old checks. Cc: Michal Wajdeczko Cc: Tvrtko Ursulin Signed-off-by: Anusha Srivatsa

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

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 the HuC is verified after it is loaded and is

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

Add debugfs entry for HuC loading status check. v2: rebased on top of drm-tip. Cc: Michal wajdeczko Tested-by: Xiang Haihao Signed-off-by: Anusha Srivatsa Signed-off-by: Alex Dai Signed-off-by:

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

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/INTEL_UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, such as 'guc' or 'guc_fw' either is

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/7] drm/i915: Name the anonymous structs inside i915_ggtt_view

== Series Details == Series: series starting with [CI,1/7] drm/i915: Name the anonymous structs inside i915_ggtt_view URL : https://patchwork.freedesktop.org/series/18006/ State : success == Summary == Series 18006v1 Series without cover letter

[Intel-gfx] [CI 4/7] drm/i915: Stop clearing i915_ggtt_view

As we now use a compact memcmp in i915_vma_compare(), we can forgo clearing the entire view and only set the precise parameters used in this view. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 1

[Intel-gfx] [CI 7/7] drm/i915: Eliminate superfluous i915_ggtt_view_normal

Since commit 058d88c4330f ("drm/i915: Track pinned VMA"), there is only one user of i915_ggtt_view_normal rodate. Just treat NULL as no special view in pin_to_display() like everywhere else. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [CI 2/7] drm/i915: Mark the ggtt_view structs as packed

In the next few patches, we will depend upon there being no uninitialised bits inside the ggtt_view. To ensure this we add the __packed attribute and double check with a build bug that gcc hasn't expanded the struct to include some padding bytes. Signed-off-by: Chris Wilson

[Intel-gfx] [CI 5/7] drm/i915: Convert i915_ggtt_view to use an anonymous union

Reading the ggtt_views is much more pleasant without the extra characters from specifying the union (i.e. ggtt_view.partial rather than ggtt_view.params.partial). To make this work inside i915_vma_compare() with only a single memcmp requires us to ensure that there are no uninitialised bytes

[Intel-gfx] [CI 6/7] drm/i915: Eliminate superfluous i915_ggtt_view_rotated

It is only being used to clear a struct and set the type, after which it is overwritten. Since we no longer check the unset bits of the union, skipping the clear is permissible. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [CI 3/7] drm/i915: Compact memcmp in i915_vma_compare()

In preparation for the next patch to convert to using an anonymous union and leaving the excess bytes in the union uninitialised, we first need to make sure we do not compare using those uninitialised bytes. We also want to preserve the compactness of the code, avoiding a second call to memcmp or

[Intel-gfx] [CI 1/7] drm/i915: Name the anonymous structs inside i915_ggtt_view

Naming this pair will become useful shortly... Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_gtt.h | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for lib/prime_numbers: Suppress warn on kmalloc failure

== Series Details == Series: lib/prime_numbers: Suppress warn on kmalloc failure URL : https://patchwork.freedesktop.org/series/18004/ State : success == Summary == Series 18004v1 lib/prime_numbers: Suppress warn on kmalloc failure

[Intel-gfx] [PATCH] lib/prime_numbers: Suppress warn on kmalloc failure

The allocation for the bitmap may become very large, larger than MAX_ORDER, for large requests. We fail gracefully by falling back to trail-division, so disable the warning from kmalloc: 521.961092] WARNING: CPU: 0 PID: 30637 at mm/page_alloc.c:3548 __alloc_pages_slowpath+0x237/0x9a0 [

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush the change in debugobject before reallocation

== Series Details == Series: drm/i915: Flush the change in debugobject before reallocation URL : https://patchwork.freedesktop.org/series/17999/ State : success == Summary == Series 17999v1 drm/i915: Flush the change in debugobject before reallocation

Re: [Intel-gfx] [PATCH v4] lib/scatterlist: Avoid potential scatterlist entry overflow

>>> @@ -402,9 +403,16 @@ int sg_alloc_table_from_pages(struct sg_table *sgt, >>> >>> /* compute number of contiguous chunks */ >>> chunks = 1; >>> - for (i = 1; i < n_pages; ++i) >>> - if (page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + >>> 1) >>> +

[Intel-gfx] [PATCH] drm/i915: Flush the change in debugobject before reallocation

When marking the debugobject as freed, be sure that write is flushed before another CPU may see it on a reallocation path. Only seen once in CI: [ 159.240873] WARNING: CPU: 3 PID: 6735 at lib/debugobjects.c:263 debug_print_object+0x87/0xb0 [ 159.240897] ODEBUG: init destroyed (active state 0)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only call skl_check_plane_surface() for visible planes (rev2)

== Series Details == Series: drm/i915: Only call skl_check_plane_surface() for visible planes (rev2) URL : https://patchwork.freedesktop.org/series/17996/ State : success == Summary == Series 17996v2 drm/i915: Only call skl_check_plane_surface() for visible planes

Re: [Intel-gfx] [PATCH 29/37] drm/i915: Fill different pages of the GTT

On Fri, Jan 13, 2017 at 09:47:08AM +0200, Joonas Lahtinen wrote: > On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > > + > > + mutex_lock(>drm.struct_mutex); > > + drm_mm_for_each_hole(node, >base.mm, this_start, this_end) { > > + u64 this_size; > > + > > + if

[Intel-gfx] [PATCH] drm/i915: Only call skl_check_plane_surface() for visible planes (v2)

When a plane is fully clipped (either because it's positioned offscreen, or because the CRTC is currently off), the clipping calculations we do during check_plane will leave nonsense/negative coordinates in plane's source rectangle. This is generally harmless since we recognize that the plane

[Intel-gfx] [PATCH] drm/i915: Only call skl_check_plane_surface() for visible planes

When a plane is fully clipped (either because it's positioned offscreen, or because the CRTC is currently off), the clipping calculations we do during check_plane will leave nonsense/negative coordinates in plane's source rectangle. This is generally harmless since we recognize that the plane

[Intel-gfx] [PATCH 3/3] intel: Support passing of explicit fencing from execbuf

From: Chris Wilson Allow the caller to pass in an fd to an array of fences to control serialisation of the execbuf in the kernel and on the GPU, and in return allow creation of a fence fd for signaling the completion (and flushing) of the batch. When the returned fence

[Intel-gfx] [PATCH 2/3] intel: Allow the client to control implicit synchronisation

From: Chris Wilson The kernel allows implicit synchronisation to be disabled on individual buffers. Use at your own risk. Signed-off-by: Chris Wilson --- intel/intel_bufmgr.h | 2 ++ intel/intel_bufmgr_gem.c | 32

[Intel-gfx] ✓ Fi.CI.BAT: success for HuC Loading Patches

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/17992/ State : success == Summary == Series 17992v1 HuC Loading Patches https://patchwork.freedesktop.org/api/1.0/series/17992/revisions/1/mbox/ Test kms_flip: Subgroup basic-plain-flip:

[Intel-gfx] [PATCH 1/3] WAIT: headers: Update drm_i915.h

Generated with `make headers_install` from tag 'chadv/test/i915-exec-fence-v03' of . TODO: Wait until header updates are in upstream kernel. References: http://git.kiwitree.net/cgit/~chadv/linux/tag/?h=chadv/test/i915-exec-fence-v03 Signed-off-by: Chad Versace ---

[Intel-gfx] [PATCH 0/3] intel: Add fence fd support to execbuf

Chris wrote these patches, and the kernel patches too. I wrote the Mesa patches that use the new feature. I'm submitting these patches myself to get things moving. This series depends on fence fd support in I915_GEM_EXECBUFFER2, which isn't upstream in the kernel yet. I tested this with kmscube

Re: [Intel-gfx] [PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

This and all the remaining patches on this series (6,7,8 and 9) got merged to dinq. Thanks for the patches. On Thu, Jan 12, 2017 at 12:12 PM, Vivi, Rodrigo wrote: > Reviewed-by: Rodrigo Vivi > > On Fri, 2017-01-13 at 00:31 +0530, vathsala

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

On Fri, Jan 13, 2017 at 06:19:53PM +, Srivatsa, Anusha wrote: > >> + /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */ > >> + I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE); This is not required on drm-tip. > >> + /* Specify auth action and where public signature is. */ >

Re: [Intel-gfx] [PATCH] dim: Triple-check and tripe warning when merging patches that touch files outside i915.

On Thu, Jan 12, 2017 at 11:04 PM, Jani Nikula wrote: > On Fri, 13 Jan 2017, Rodrigo Vivi wrote: >> Most of commiters already knows that by heart and also dim already >> have this warning. So maybe this is just Bart writing to blackboard. Duh! >> >>

Re: [Intel-gfx] [PATCH 35/37] drm/i915: Live testing for context execution

On Fri, Jan 13, 2017 at 04:28:58PM +0200, Joonas Lahtinen wrote: > On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > > > For future synchronization purposes, maybe document where the below was > cloned from? It is a routine I've written many times. > > + offset = PAGE_SIZE * first_page

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Move GuC log related functions into dedicated file

== Series Details == Series: drm/i915/guc: Move GuC log related functions into dedicated file URL : https://patchwork.freedesktop.org/series/17988/ State : success == Summary == Series 17988v1 drm/i915/guc: Move GuC log related functions into dedicated file

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

>-Original Message- >From: Wajdeczko, Michal >Sent: Friday, January 13, 2017 10:18 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Chris Wilson ; >Hiler, Arkadiusz ; Alex Dai

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

On Fri, Jan 13, 2017 at 10:08:42AM -0800, Anusha Srivatsa wrote: > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of drm-tip. Changed name format and upped > version 1.7. > v3: changed wait_for_atomic to wait_for >

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

The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-tip. Changed name format and upped version 1.7. v3: changed wait_for_atomic to wait_for v4: rebased. Rename intel_huc_auh() to intel_guc_auth_huc() and place the

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

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: rebased on-top of drm-intel-nightly v3: rebased.

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

Add debugfs entry for HuC loading status check. v2: rebased on top of drm-tip. Cc: Michal wajdeczko Tested-by: Xiang Haihao Signed-off-by: Anusha Srivatsa Signed-off-by: Alex Dai Signed-off-by:

[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 on top of drm-tip. Rename KBL_FW_ to KBL_HUC_FW_ v3: rebased. Remove old checks. Cc: Michal Wajdeczko Cc: Tvrtko Ursulin Signed-off-by: Anusha Srivatsa

[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 on to top drm-tip. Rename BXT_FW_MAJOR to BXT_HUC_FW_ Cc: Micha Wajdeczko Cc: Tvrtko Ursulin

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

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 the HuC is verified after it is loaded and is

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

The 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 if

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

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/INTEL_UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, such as 'guc' or 'guc_fw' either is

[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.

Re: [Intel-gfx] [RFC] drm/i915/guc: Move GuC log related functions into dedicated file

On Fri, Jan 13, 2017 at 05:41:57PM +, Michal Wajdeczko wrote: > Functions supporting GuC logging capabilities were spread across > many files, with unnecessary exposures and mixed with unrelated > code. Dedicate file will make maintenance of all GuC functions > easier as more functions are

[Intel-gfx] [RFC] drm/i915/guc: Move GuC log related functions into dedicated file

Functions supporting GuC logging capabilities were spread across many files, with unnecessary exposures and mixed with unrelated code. Dedicate file will make maintenance of all GuC functions easier as more functions are coming to support GuC submissions. Signed-off-by: Michal Wajdeczko

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

>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Friday, January 13, 2017 9:16 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine > >Subject: Re:

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

>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Friday, January 13, 2017 9:25 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Hiler, Arkadiusz >; >Wajdeczko, Michal

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

On Fri, Jan 13, 2017 at 09:07:08AM -0800, Anusha Srivatsa wrote: > +/** > + * intel_guc_auth_huc() - authenticate ucode > + * @dev_priv: the drm_i915_device > + * > + * Triggers a HuC fw authentication request to the GuC via intel_guc_action_ > + * authenticate_huc interface. > + */ > +void

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

On Fri, Jan 13, 2017 at 09:06:34AM -0800, Anusha Srivatsa wrote: > +/** > + * huc_ucode_xfer() - DMA's the firmware > + * @dev_priv: the drm_i915_private device > + * > + * Transfer the firmware image to RAM for execution by the microcontroller. > + * > + * Return: 0 on success, non-zero on

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

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 the HuC is verified after it is loaded and is

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

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: rebased on-top of drm-intel-nightly v3: rebased.

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

The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-tip. Changed name format and upped version 1.7. v3: changed wait_for_atomic to wait_for v4: rebased. Rename intel_huc_auh() to intel_guc_auth_huc() and place the

[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 on top of drm-tip. Rename KBL_FW_ to KBL_HUC_FW_ v3: rebased. Remove old checks. Cc: Michal Wajdeczko Cc: Tvrtko Ursulin Signed-off-by: Anusha Srivatsa

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

Add debugfs entry for HuC loading status check. v2: rebased on top of drm-tip. Cc: Michal wajdeczko Tested-by: Xiang Haihao Signed-off-by: Anusha Srivatsa Signed-off-by: Alex Dai Signed-off-by:

[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 on to top drm-tip. Rename BXT_FW_MAJOR to BXT_HUC_FW_ Cc: Micha Wajdeczko Cc: Tvrtko Ursulin

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

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/INTEL_UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, such as 'guc' or 'guc_fw' either is

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

The 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 if

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

The 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 if

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

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/INTEL_UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, such as 'guc' or 'guc_fw' either is

Re: [Intel-gfx] [RFC 1/4] x86/platform/intel/iosf_mbi: Add a mutex for punit access

On Fri, Jan 13, 2017 at 05:06:52PM +0100, Hans de Goede wrote: > Hi, > > On 01/13/2017 10:26 AM, Ville Syrjälä wrote: > > On Mon, Jan 02, 2017 at 03:21:13PM +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 02-01-17 15:12, Ville Syrjälä wrote: > >>> On Sun, Jan 01, 2017 at 09:14:00PM +0100, Hans

Re: [Intel-gfx] [RFC 1/4] x86/platform/intel/iosf_mbi: Add a mutex for punit access

Hi, On 01/13/2017 10:26 AM, Ville Syrjälä wrote: On Mon, Jan 02, 2017 at 03:21:13PM +0100, Hans de Goede wrote: Hi, On 02-01-17 15:12, Ville Syrjälä wrote: On Sun, Jan 01, 2017 at 09:14:00PM +0100, Hans de Goede wrote: The punit on baytrail / cherrytrail systems is not only accessed through

[Intel-gfx] State of development of X11 driver

Hello, As you may or may not be aware many distributions are switching from the xf86-video-intel driver to the modesetting driver (with Glamor acceleration). Debian, Arch, and now Fedora are unhappy that there has not been a stable release of the driver in years. - Have any of the

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Add MIPI_IO WA

On Fri, Jan 13, 2017 at 05:03:33PM +0200, Imre Deak wrote: > On pe, 2017-01-13 at 09:55 +0200, Jani Nikula wrote: > > On Thu, 12 Jan 2017, Mika Kahola wrote: > > > This is definitely needed to pass igt test on bxt > > > > > > 'gem_exec_suspend --run-subtest basic-S3' > > >

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Add MIPI_IO WA

On pe, 2017-01-13 at 09:55 +0200, Jani Nikula wrote: > On Thu, 12 Jan 2017, Mika Kahola wrote: > > This is definitely needed to pass igt test on bxt > > > > 'gem_exec_suspend --run-subtest basic-S3' > > > > Tested-by: Mika Kahola > > > > On Mon,

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 12/01/17 10:21, Chris Wilson wrote: > On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote: >> On 11/01/17 18:08, Chris Wilson wrote: >>> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: With kernel 4.10rc3 running as Xen dm0 I get at each boot: [

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

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/INTEL_UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, such as 'guc' or 'guc_fw' either is

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

The 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 if

Re: [Intel-gfx] [PATCH 35/37] drm/i915: Live testing for context execution

On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > Check we can create and execution within a context. > > Signed-off-by: Chris Wilson > +static struct i915_vma * > +gpu_fill_pages(struct i915_vma *vma, > +    unsigned long first_page, > +    

Re: [Intel-gfx] [PATCH 19/37] drm/i915: Test coherency of and barriers between cache domains

On Fri, Jan 13, 2017 at 11:44:23AM +, Matthew Auld wrote: > On 11 January 2017 at 21:09, Chris Wilson wrote: > > Write into an object using WB, WC, GTT, and GPU paths and make sure that > > our internal API is sufficient to ensure coherent reads and writes. > > > >

Re: [Intel-gfx] [PATCH 34/37] drm/i915: Test creation of partial VMA

On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > Mock testing to ensure we can create and lookup partial VMA. > > Signed-off-by: Chris Wilson > +static int igt_vma_partial(void *arg) > +{ > + struct drm_i915_private *i915 = arg; > + const unsigned int

Re: [Intel-gfx] [PATCH 32/37] drm/i915: Exercise i915_vma_pin/i915_vma_insert

On Fri, Jan 13, 2017 at 02:49:49PM +0200, Joonas Lahtinen wrote: > On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > > High-level testing of the struct drm_mm by verifying our handling of > > weird requests to i915_vma_pin. > > > > Signed-off-by: Chris Wilson > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unused function intel_ddi_get_link_dpll()

== Series Details == Series: drm/i915: Remove unused function intel_ddi_get_link_dpll() URL : https://patchwork.freedesktop.org/series/17963/ State : success == Summary == Series 17963v1 drm/i915: Remove unused function intel_ddi_get_link_dpll()

Re: [Intel-gfx] [PATCH 31/37] drm/i915: Test creation of VMA

On Fri, Jan 13, 2017 at 02:28:54PM +0200, Joonas Lahtinen wrote: > On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > > Simple test to exercise creation and lookup of VMA within an object. > > > > Signed-off-by: Chris Wilson > > > > > +static int

Re: [Intel-gfx] [PATCH 32/37] drm/i915: Exercise i915_vma_pin/i915_vma_insert

On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > High-level testing of the struct drm_mm by verifying our handling of > weird requests to i915_vma_pin. > > Signed-off-by: Chris Wilson > +static int igt_vma_pin1(void *arg) > +{ > + struct drm_i915_private

Re: [Intel-gfx] [PATCH 31/37] drm/i915: Test creation of VMA

On ke, 2017-01-11 at 21:09 +, Chris Wilson wrote: > Simple test to exercise creation and lookup of VMA within an object. > > Signed-off-by: Chris Wilson > +static int vma_create(struct drm_i915_private *i915, > +   struct list_head *objects, > +

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

On Thu, Jan 12, 2017 at 08:51:22AM -0800, Anusha Srivatsa wrote: > 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

[Intel-gfx] [PATCH] drm/i915: Remove unused function intel_ddi_get_link_dpll()

The function intel_ddi_get_link_dpll() was added in f169660ed4e5 ("drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT") to "allow for the implementation of a platform neutral upfront link training function", but such implementation never landed. So remove that

Re: [Intel-gfx] [RFC 1/4] x86/platform/intel/iosf_mbi: Add a mutex for punit access

On Fri, Jan 13, 2017 at 01:12:15PM +0200, Jarkko Nikula wrote: > On 01/13/2017 12:51 PM, Ville Syrjälä wrote: > > On Fri, Jan 13, 2017 at 12:34:54PM +0200, Jarkko Nikula wrote: > >> On 01/13/2017 11:26 AM, Ville Syrjälä wrote: > >>> It also feels quite hand wavy since the punit could do whatever

Re: [Intel-gfx] [PATCH 19/37] drm/i915: Test coherency of and barriers between cache domains

On 11 January 2017 at 21:09, Chris Wilson wrote: > Write into an object using WB, WC, GTT, and GPU paths and make sure that > our internal API is sufficient to ensure coherent reads and writes. > > Signed-off-by: Chris Wilson > --- >

Re: [Intel-gfx] Anonymoose ggtt_view_params

On Fri, Jan 13, 2017 at 11:23:47AM +, Tvrtko Ursulin wrote: > > On 13/01/2017 11:11, Chris Wilson wrote: > >On Fri, Jan 13, 2017 at 10:59:46AM +, Tvrtko Ursulin wrote: > >> > >>On 13/01/2017 10:33, Chris Wilson wrote: > >>>Ok, ok, this cover note only exists to continue the run on joke of

Re: [Intel-gfx] [PATCH v3 5/7] drm/i915: Convert i915_ggtt_view to use an anonymous union

On pe, 2017-01-13 at 10:33 +, Chris Wilson wrote: > Reading the ggtt_views is much more pleasant without the extra > characters from specifying the union (i.e. ggtt_view.partial rather than > ggtt_view.params.partial). To make this work inside i915_vma_compare() > with only a single memcmp

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/7] drm/i915: Name the anonymous structs inside i915_ggtt_view

== Series Details == Series: series starting with [v3,1/7] drm/i915: Name the anonymous structs inside i915_ggtt_view URL : https://patchwork.freedesktop.org/series/17960/ State : success == Summary == Series 17960v1 Series without cover letter

Re: [Intel-gfx] Anonymoose ggtt_view_params

On 13/01/2017 11:11, Chris Wilson wrote: On Fri, Jan 13, 2017 at 10:59:46AM +, Tvrtko Ursulin wrote: On 13/01/2017 10:33, Chris Wilson wrote: Ok, ok, this cover note only exists to continue the run on joke of my mispellings! Everything but [5/7] drm/i915: Convert i915_ggtt_view to use

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Add MIPI_IO WA

On Fri, 2017-01-13 at 09:55 +0200, Jani Nikula wrote: > On Thu, 12 Jan 2017, Mika Kahola wrote: > > > > This is definitely needed to pass igt test on bxt > > > > 'gem_exec_suspend --run-subtest basic-S3' > > > > Tested-by: Mika Kahola > > > > On

Re: [Intel-gfx] [PATCH v3 5/7] drm/i915: Convert i915_ggtt_view to use an anonymous union

On 13/01/2017 10:33, Chris Wilson wrote: Reading the ggtt_views is much more pleasant without the extra characters from specifying the union (i.e. ggtt_view.partial rather than ggtt_view.params.partial). To make this work inside i915_vma_compare() with only a single memcmp requires us to ensure

Re: [Intel-gfx] [RFC 1/4] x86/platform/intel/iosf_mbi: Add a mutex for punit access

On 01/13/2017 12:51 PM, Ville Syrjälä wrote: On Fri, Jan 13, 2017 at 12:34:54PM +0200, Jarkko Nikula wrote: On 01/13/2017 11:26 AM, Ville Syrjälä wrote: It also feels quite hand wavy since the punit could do whatever at any time AFAIK. Eg. if there's some thermal event or something the punit

Re: [Intel-gfx] Anonymoose ggtt_view_params

On Fri, Jan 13, 2017 at 10:59:46AM +, Tvrtko Ursulin wrote: > > On 13/01/2017 10:33, Chris Wilson wrote: > >Ok, ok, this cover note only exists to continue the run on joke of my > >mispellings! > > > >Everything but > >[5/7] drm/i915: Convert i915_ggtt_view to use an anonymous union > >has a

Re: [Intel-gfx] Anonymoose ggtt_view_params

On 13/01/2017 10:33, Chris Wilson wrote: Ok, ok, this cover note only exists to continue the run on joke of my mispellings! Everything but [5/7] drm/i915: Convert i915_ggtt_view to use an anonymous union has a r-b, so this is a good time to complain if this is too much of a hack. If you

Re: [Intel-gfx] [RFC 1/4] x86/platform/intel/iosf_mbi: Add a mutex for punit access

On Fri, Jan 13, 2017 at 12:34:54PM +0200, Jarkko Nikula wrote: > On 01/13/2017 11:26 AM, Ville Syrjälä wrote: > > It also feels quite hand wavy since the punit could do whatever at > > any time AFAIK. Eg. if there's some thermal event or something the > > punit might kick into action. So trying to

Re: [Intel-gfx] [PATCH 02/37] drm/i915: Provide a hook for selftests

On 13/01/2017 10:22, Chris Wilson wrote: On Fri, Jan 13, 2017 at 10:12:16AM +, Tvrtko Ursulin wrote: On 13/01/2017 08:31, Chris Wilson wrote: On Wed, Jan 11, 2017 at 09:09:02PM +, Chris Wilson wrote: Some pieces of code are independent of hardware but are very tricky to exercise

Re: [Intel-gfx] [RFC 1/4] x86/platform/intel/iosf_mbi: Add a mutex for punit access

On 01/13/2017 11:26 AM, Ville Syrjälä wrote: It also feels quite hand wavy since the punit could do whatever at any time AFAIK. Eg. if there's some thermal event or something the punit might kick into action. So trying to protect this from the OS side might not be able to avoid these problems

[Intel-gfx] [PATCH v3 7/7] drm/i915: Eliminate superfluous i915_ggtt_view_normal

Since commit 058d88c4330f ("drm/i915: Track pinned VMA"), there is only one user of i915_ggtt_view_normal rodate. Just treat NULL as no special view in pin_to_display() like everywhere else. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 6/7] drm/i915: Eliminate superfluous i915_ggtt_view_rotated

It is only being used to clear a struct and set the type, after which it is overwritten. Since we no longer check the unset bits of the union, skipping the clear is permissible. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 5/7] drm/i915: Convert i915_ggtt_view to use an anonymous union

Reading the ggtt_views is much more pleasant without the extra characters from specifying the union (i.e. ggtt_view.partial rather than ggtt_view.params.partial). To make this work inside i915_vma_compare() with only a single memcmp requires us to ensure that there are no uninitialised bytes

  1   2   >