Re: [Intel-gfx] [PATCH v3] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

Since this patch has been on hold for a little bit, I did a bit of thinking of how we could this a little more cleanly. Unfortunately I couldn't think of a way, however I did think of an alternative solution: I'm planning on backporting all of the skl wm fixes already, so I'm going to use this

Re: [Intel-gfx] [PATCH 12/14] drm/i915: Reverse the loop in intel_dp_compute_config

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > While configuring the pipe during modeset, it should loop > starting from max clock and max lane count reducing the > lane count and clock in each iteration until the requested mode > rate is less than or equal to available link BW. > >

Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > From: Jim Bride > > Add the PLL selection code for HSW/BDW/BXT/SKL into a stand-alone function > in order to allow for the implementation of a platform neutral upfront > link training function. > > v3: > * Add

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fallback to lower link rate and lane count during link training

On Fri, Sep 02, 2016 at 07:52:53PM +, Pandiyan, Dhinakaran wrote: > On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > > According to the DisplayPort Spec, in case of Clock Recovery failure > > the link training sequence should fall back to the lower link rate > > followed by lower lane

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fallback to lower link rate and lane count during link training

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > According to the DisplayPort Spec, in case of Clock Recovery failure > the link training sequence should fall back to the lower link rate > followed by lower lane count until CR succeeds. > On CR success, the sequence proceeds with Channel

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Make DP link training channel equalization DP 1.2 Spec compliant

On Fri, 2016-09-02 at 14:20 +0300, Mika Kahola wrote: > On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > > Fix the number of tries in channel euqalization link training > > sequence > > according to DP 1.2 Spec. It returns a boolean depending on channel > > equalization pass or failure. >

Re: [Intel-gfx] S4 resume breakage with i915 driver

On 29/08/16 14:32, Daniel Vetter wrote: On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote: On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote: On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote: On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote: On Fri, 26 Aug 2016

Re: [Intel-gfx] [PATCH 14/18] drm/i915/guc: Prepare for nonblocking execbuf submission

On 30/08/16 09:18, Chris Wilson wrote: Currently the presumption is that the request construction and its submission to the GuC are all under the same holding of struct_mutex. We wish to relax this to separate the request construction and the later submission to the GuC. This requires us to

Re: [Intel-gfx] [PATCH 09/14] drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2

On Fri, 2016-09-02 at 12:16 +0300, Mika Kahola wrote: > On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > > From: Dhinakaran Pandiyan > > > > This function cleans up clock recovery loop in link training > > compliant > > tp Dp Spec 1.2. It tries the clock

[Intel-gfx] [PATCH v5] drm/i915/dp: DP audio API changes for MST

DP MST provides the capability to send multiple video and audio streams through a single port. This requires the API's between i915 and audio drivers to distinguish between multiple audio capable displays that can be connected to a port. Currently only the port identity is shared in the APIs. This

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: start adding dp mst audio

This looks fine to me. Reviewed-by: Lyude On Wed, 2016-08-24 at 00:23 -0700, Dhinakaran Pandiyan wrote: > From: Libin Yang > > (This patch is developed by Dave Airlie > originally) > > This patch adds support for DP MST audio

Re: [Intel-gfx] [PATCH 18/18] drm/i915: Support explicit fencing for execbuf

On 30/08/2016 09:18, Chris Wilson wrote: Now that the user can opt-out of implicit fencing, we need to give them back control over the fencing. We employ sync_file to wrap our drm_i915_gem_request and provide an fd that userspace can merge with other sync_file fds and pass back to the kernel to

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: read out slice/subslice masks (rev2)

On to, 2016-09-01 at 09:50 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: read out slice/subslice masks (rev2) > URL   : https://patchwork.freedesktop.org/series/33/ > State : failure > > == Summary == > > Series 33v2 drm/i915: read out slice/subslice masks >

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Nonblocking request submission

On 30/08/2016 09:18, Chris Wilson wrote: Now that we have fences in place to drive request submission, we can employ those to queue requests after their dependencies as opposed to stalling in the middle of an execbuf ioctl. (However, we still choose to spin before enabling the IRQ as that is

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Use new CRC debugfs API

Hi Tomeu, IMHO it would be better to split out the refactoring into preparatory patch. It brings a minor change which (not 100% sure on that) should not cause issues but is worth pointing out. On 5 August 2016 at 11:45, Tomeu Vizoso wrote: > +static int

[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.16

Hello, A new intel-gpu-tools quarterly release is available with the following changes: - Build automatically tests required when issueing a make check, Tests/subtests that receive a crash signal should print a backtrace when i-g-t is built with libunwind support (Marius Vlad) - lib/igt_kms:

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Em Sex, 2016-09-02 às 05:58 +, Pandiyan, Dhinakaran escreveu: > On Mon, 2016-08-15 at 19:36 -0300, Paulo Zanoni wrote: > > > > Ever since I started working on FBC I was already aware that FBC > > can > > really amplify the FIFO underrun symptoms. On systems where FIFO > > underruns were

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list

On Fri, Sep 02, 2016 at 02:20:16PM +0100, John Harrison wrote: > On 02/09/2016 12:02, Chris Wilson wrote: > >On Fri, Sep 02, 2016 at 11:59:12AM +0100, Chris Wilson wrote: > >>On Fri, Sep 02, 2016 at 11:30:18AM +0100, John Harrison wrote: > + if (request->file_priv) { > >>>Why check for

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list

On 02/09/2016 12:02, Chris Wilson wrote: On Fri, Sep 02, 2016 at 11:59:12AM +0100, Chris Wilson wrote: On Fri, Sep 02, 2016 at 11:30:18AM +0100, John Harrison wrote: + if (request->file_priv) { Why check for request->file_priv again? The block above will exit if it is null. There surely

Re: [Intel-gfx] [PATCH 12/14] drm/i915: Reverse the loop in intel_dp_compute_config

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > While configuring the pipe during modeset, it should loop > starting from max clock and max lane count reducing the > lane count and clock in each iteration until the requested mode > rate is less than or equal to available link BW. > >

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fallback to lower link rate and lane count during link training

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > According to the DisplayPort Spec, in case of Clock Recovery failure > the link training sequence should fall back to the lower link rate > followed by lower lane count until CR succeeds. > On CR success, the sequence proceeds with Channel

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fallback to lower link rate and lane count during link training

On Thu, Sep 01, 2016 at 03:08:16PM -0700, Manasi Navare wrote: > According to the DisplayPort Spec, in case of Clock Recovery failure > the link training sequence should fall back to the lower link rate > followed by lower lane count until CR succeeds. > On CR success, the sequence proceeds with

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

Em Sex, 2016-09-02 às 17:16 +0530, Mahesh Kumar escreveu: > Hi, > > On Wednesday 31 August 2016 07:17 PM, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu: > > > > > > Hi > > > > > > Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu: > > > > >

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fallback to lower link rate and lane count during link training

On Thu, Sep 01, 2016 at 03:08:16PM -0700, Manasi Navare wrote: > According to the DisplayPort Spec, in case of Clock Recovery failure > the link training sequence should fall back to the lower link rate > followed by lower lane count until CR succeeds. > On CR success, the sequence proceeds with

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

Hi, On Wednesday 31 August 2016 07:17 PM, Zanoni, Paulo R wrote: Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu: Hi Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu: This patch enables Transition WM for SKL+ platforms. Transition WM are used if IPC is enabled, to

Re: [Intel-gfx] [PATCH] drm/i915: Cleanup i915_param()

On Fri, Sep 02, 2016 at 01:46:17PM +0300, David Weinehall wrote: > Rather than having a separate case for each value where we just return > a hardcoded value = 1, we lump them all together and rely on the awesome > case-fallthrough feature of C. > > Fix all feature macros to pass dev_priv instead

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Make DP link training channel equalization DP 1.2 Spec compliant

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > Fix the number of tries in channel euqalization link training > sequence > according to DP 1.2 Spec. It returns a boolean depending on channel > equalization pass or failure. > > Signed-off-by: Dhinakaran Pandiyan

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Cleanup i915_param()

== Series Details == Series: drm/i915: Cleanup i915_param() URL : https://patchwork.freedesktop.org/series/11932/ State : warning == Summary == Series 11932v1 drm/i915: Cleanup i915_param() http://patchwork.freedesktop.org/api/1.0/series/11932/revisions/1/mbox/ Test kms_flip:

[Intel-gfx] [PATCH xf86-video-intel] uxa: only call intel_sync_close when built with HAVE_DRI3

Avoid calling a function only built with dri3, fixes an undefined symbol crash when opting into uxa reported by Walter Alejandro Iglesias when running OpenBSD. Signed-off-by: Jonathan Gray --- src/uxa/intel_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [Intel-gfx] igt/gem_exec_nop parallel test: why it isn't useful

On 01/09/16 21:00, Chris Wilson wrote: On Thu, Sep 01, 2016 at 05:51:09PM +0100, Dave Gordon wrote: The gem_exec_nop test generally works by submitting batches to an engine as fast as possible for a fixed time, then finally calling gem_sync() to wait for the last submitted batch to complete.

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list

On Fri, Sep 02, 2016 at 11:59:12AM +0100, Chris Wilson wrote: > On Fri, Sep 02, 2016 at 11:30:18AM +0100, John Harrison wrote: > > >+ if (request->file_priv) { > > Why check for request->file_priv again? The block above will exit if > > it is null. There surely can't be a race with

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list

On Fri, Sep 02, 2016 at 11:30:18AM +0100, John Harrison wrote: > On 22/08/2016 09:03, Chris Wilson wrote: > >Adding to the tail of the client request list as the only other user is > >in the throttle ioctl that iterates forwards over the list. It only > >needs protection against deletion of a

[Intel-gfx] [PATCH] drm/i915: Cleanup i915_param()

Rather than having a separate case for each value where we just return a hardcoded value = 1, we lump them all together and rely on the awesome case-fallthrough feature of C. Fix all feature macros to pass dev_priv instead of dev while at it, and use INTEL_GEN() instead of INTEL_INFO()->gen.

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list

On 22/08/2016 09:03, Chris Wilson wrote: Adding to the tail of the client request list as the only other user is in the throttle ioctl that iterates forwards over the list. It only needs protection against deletion of a request as it reads it, it simply won't see a new request added to the end

Re: [Intel-gfx] [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]

On 8/31/2016 9:39 PM, Daniel Vetter wrote: Big thing is untangling and carefully documenting the different uapi types of planes. I also sprinkled a few more cross references around to make this easier to discover. As usual, remove the kerneldoc for internal functions which are not exported.

Re: [Intel-gfx] [PATCH 02/10] drm: Extract drm_bridge.h

On 8/31/2016 9:39 PM, Daniel Vetter wrote: We don't want to burry the bridge structures kerneldoc in drm_crtc.h. Cc: Archit Taneja Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter ---

Re: [Intel-gfx] [PATCH 09/14] drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > From: Dhinakaran Pandiyan > > This function cleans up clock recovery loop in link training > compliant > tp Dp Spec 1.2. It tries the clock recovery 5 times for the same > voltage > or until max voltage

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

uto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Peter-Antoine/HuC-Loading-Patches/20160902-161205 config: i386-randconfig-s1-201

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

This patch adds the HuC Loading for the BXT. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased. changed file name to match the install package format. v7: rebased. Signed-off-by: Peter Antoine Reviewed-by: David Gordon ---

[Intel-gfx] [PATCH v4 0/2] HuC/GuC status to Get Params.

As it states on the tin. Add the HuC/GuC patches to the Get params so that they can be accessed from userspace. This is a requirement for the opensourcing of media codecs that require the HuC/GuC. These patches require the HuC enabling patches. patchset: HuC Loading Patches. v2: removed extra

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

Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. Signed-off-by: Alex Dai Signed-off-by: Peter Antoine Reviewed-by: Dave Gordon ---

[Intel-gfx] [PATCH v7 5/6] 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-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed wait_for_automic to wait_for v5: rebased. v7: rebased.

[Intel-gfx] [PATCH v4 1/2] drm/i915/get_params: Add GuC status to getparams

This patch returns the GuC status to the caller. It is used so that the userspace knows if the GuC has been loaded. v4: rebase. Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_drv.c | 4 drivers/gpu/drm/i915/intel_guc.h| 2 +-

[Intel-gfx] [PATCH v4 2/2] 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 v7 2/6] 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 v7 3/6] 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 v7 0/6] HuC Loading Patches

This patch series enables the HuC loading. These patches are a port of the patches that were created by Yu Dai (Alex) and have been ported to work with the new GuC patches. The series include a patch to enable the HuC on BXT. This is a separate patch as the state of the BXT HuC firmware is still

[Intel-gfx] [PATCH v7 1/6] 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/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 renamed to

Re: [Intel-gfx] [PATCH 08/14] drm/i915/dp: Move max. vswing check to it's own function

+1 for this cleanup Reviewed-by: Mika Kahola On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > From: Dhinakaran Pandiyan > > Wrap the max. vswing check in a separate function. > This makes the clock recovery phase of DP link

Re: [Intel-gfx] [alsa-devel] [PATCH v4] drm/i915/dp: DP audio API changes for MST

> -Original Message- > From: alsa-devel-boun...@alsa-project.org [mailto:alsa-devel- > boun...@alsa-project.org] On Behalf Of Pandiyan, Dhinakaran > Sent: Thursday, September 1, 2016 3:48 PM > To: intel-gfx@lists.freedesktop.org > Cc: alsa-de...@alsa-project.org; ti...@suse.de;

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: - skl wm fixes (Lyude, Matt, Maarten) - cleanup of kdev/drm_dev/i915_dev handling (David Weinehall) - make (most) encoders take advantage of atomic states (Maarten) - MMAP_GTT_VERSION driver param to announce that gtt mmaps are reliable (Chris) - allow