Re: [Intel-gfx] [i-g-t PATCH] lib: add option for running generic tests cases only

On 11/28/2016 02:20 PM, Chris Wilson wrote: > On Mon, Nov 28, 2016 at 01:07:36PM +0100, Maarten Lankhorst wrote: >> Op 28-11-16 om 10:37 schreef Abdiel Janulgue: >>> Pretend to run on a non-intel machine even when running on i915.ko, >>> so that we could run and gather passrate data. > > What

Re: [Intel-gfx] [RFC PATCH v3 2/7] drm/i915: Add support for audio driver notifications

On Mon, 28 Nov 2016 22:56:24 +0100, Pierre-Louis Bossart wrote: > > On 11/28/16 1:30 PM, Ville Syrjälä wrote: > > On Mon, Nov 28, 2016 at 01:13:31PM -0600, Pierre-Louis Bossart wrote: > >> > >> On 11/28/16 11:01 AM, Ville Syrjälä wrote: > +if (pdata->notify_audio_lpe)

[Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

For LSPCON initialization during system resume we need AUX functionality, but we call the corresponding encoder reset hook with all interrupts disabled. Without interrupts we'll do a poll-wait for AUX transfer completions, which adds a significant delay if the transfers timeout/need to be retried

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: use DRM_INFO for userspace issues

== Series Details == Series: drm/i915/perf: use DRM_INFO for userspace issues URL : https://patchwork.freedesktop.org/series/16112/ State : success == Summary == Series 16112v1 drm/i915/perf: use DRM_INFO for userspace issues

Re: [Intel-gfx] [PATCH i-g-t v3] lib/debugfs: Support new generic ABI for CRC capture

Hi tomeu, This patch does not seem to apply cleanly on upstream/master. Rob. > The kernel has now a new debugfs ABI that can also allow capturing > frame > CRCs for drivers other than i915. > > Add alternative codepaths so the new ABI is used if the kernel is > recent > enough, and fall back

Re: [Intel-gfx] [PATCH v2 2/3] drm: Pull together probe + setup for drm_fb_helper

On Tue, Nov 29, 2016 at 11:26 PM, Chris Wilson wrote: > On Tue, Nov 29, 2016 at 09:29:06PM +0100, Daniel Vetter wrote: >> On Tue, Nov 29, 2016 at 12:02:16PM +, Chris Wilson wrote: >> > drm_fb_helper_probe_connector_modes() is always called before >> >

Re: [Intel-gfx] [PATCH v2 2/3] drm: Pull together probe + setup for drm_fb_helper

On Tue, Nov 29, 2016 at 09:29:06PM +0100, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 12:02:16PM +, Chris Wilson wrote: > > drm_fb_helper_probe_connector_modes() is always called before > > drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a > > small bit of code compaction.

Re: [Intel-gfx] [PATCH] drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

On Tue, Nov 29, 2016 at 02:40:45PM +, Matthew Auld wrote: > On 29 November 2016 at 14:13, wrote: > > From: Ville Syrjälä > > > > Looks like we're only initializing dev_priv->atomic_cdclk_freq > > at resume and commit times, not

Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

On Tue, 2016-11-29 at 21:55 +0200, Ville Syrjälä wrote: > On Tue, Nov 29, 2016 at 09:40:29PM +0200, Imre Deak wrote: > > For LSPCON initialization during system resume we need AUX > > functionality, but we call the corresponding encoder reset hook with all > > interrupts disabled. Without

Re: [Intel-gfx] [PATCH] drm/i915/perf: use DRM_INFO for userspace issues

On Tue, Nov 29, 2016 at 04:57:59PM +, Robert Bragg wrote: > Avoid using DRM_ERROR for conditions userspace can trigger with a bad > config when opening a stream or from not reading data in a timely > fashion (whereby the OA buffer fills up). These conditions are tested > by i-g-t which treats

Re: [Intel-gfx] [PATCH i-g-t 0/2] Improve error report when there are less overlays than expected

Hi tomeu, This series looks good to me, feel free to add my r-b. Rob. > Hi, > > kms_plane_scaling would happily try to use the cursor plane as if it > was an > overlay, and the first signal of it would be the kernel refusing the > SetPlane > call because of the pixel format not matching. > >

Re: [Intel-gfx] [PULL] drm-misc-next

Hi Daniel, On Tue, 29 Nov 2016 12:17:15 +0100 Daniel Vetter wrote: > > drm-misc has slightly moved around, new branches for you to pull in: > > git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes > git://anongit.freedesktop.org/drm/drm-misc for-linux-next >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lspcon: Enable AUX interrupts for resume time initialization (rev2)

== Series Details == Series: drm/i915/lspcon: Enable AUX interrupts for resume time initialization (rev2) URL : https://patchwork.freedesktop.org/series/16106/ State : success == Summary == Series 16106v2 drm/i915/lspcon: Enable AUX interrupts for resume time initialization

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

On Tue, Nov 29, 2016 at 9:45 AM, Sean Paul wrote: > On Mon, Nov 28, 2016 at 7:59 PM, Manasi Navare > wrote: >> On Wed, Nov 23, 2016 at 09:09:28AM +0100, Daniel Vetter wrote: >>> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote: >>> > On

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

On Tue, Nov 15, 2016 at 12:59:06PM -0800, Dhinakaran Pandiyan wrote: > Not validating the mode rate against max. link rate results in not pruning > invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not > support 4k@60Hz. But, we do not reject this mode. > > So, make use of the

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/perf: More documentation hooked to i915.rst

== Series Details == Series: drm/i915/perf: More documentation hooked to i915.rst URL : https://patchwork.freedesktop.org/series/16114/ State : warning == Summary == Series 16114v1 drm/i915/perf: More documentation hooked to i915.rst

Re: [Intel-gfx] [PATCH 2/3] drm/dp/mst: Calculate total link bandwidth instead of hardcoding it

On Tue, 2016-11-29 at 22:58 +0200, Ville Syrjälä wrote: > On Thu, Nov 17, 2016 at 06:03:47PM -0800, Dhinakaran Pandiyan wrote: > > The total or the nominal link bandwidth, which we save in terms of PBN, is > > a factor of link rate and lane count. But, currently we hardcode it to > > 2560 PBN.

Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

On Tue, Nov 29, 2016 at 10:41:45PM +0200, Imre Deak wrote: > On Tue, 2016-11-29 at 22:27 +0200, Ville Syrjälä wrote: > > On Tue, Nov 29, 2016 at 10:14:23PM +0200, Imre Deak wrote: > > > On Tue, 2016-11-29 at 21:55 +0200, Ville Syrjälä wrote: > > > > On Tue, Nov 29, 2016 at 09:40:29PM +0200, Imre

Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

On Tue, Nov 29, 2016 at 10:14:23PM +0200, Imre Deak wrote: > On Tue, 2016-11-29 at 21:55 +0200, Ville Syrjälä wrote: > > On Tue, Nov 29, 2016 at 09:40:29PM +0200, Imre Deak wrote: > > > For LSPCON initialization during system resume we need AUX > > > functionality, but we call the corresponding

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

On Tue, Nov 29, 2016 at 02:43:55PM -0500, Sean Paul wrote: > On Tue, Nov 29, 2016 at 9:45 AM, Sean Paul wrote: > > On Mon, Nov 28, 2016 at 7:59 PM, Manasi Navare > > wrote: > >> On Wed, Nov 23, 2016 at 09:09:28AM +0100, Daniel Vetter wrote: > >>>

Re: [Intel-gfx] [PATCH 2/3] drm/dp/mst: Calculate total link bandwidth instead of hardcoding it

On Thu, Nov 17, 2016 at 06:03:47PM -0800, Dhinakaran Pandiyan wrote: > The total or the nominal link bandwidth, which we save in terms of PBN, is > a factor of link rate and lane count. But, currently we hardcode it to > 2560 PBN. This results in incorrect computation of total slots. > > E.g, 2

Re: [Intel-gfx] [PATCH v2 3/3] drm: Protect fb_helper list manipulation with a mutex

On Tue, Nov 29, 2016 at 7:02 AM, Chris Wilson wrote: > Though we only walk the kernel_fb_helper_list inside a panic (or single > thread debugging), we still need to protect the list manipulation on > creating/removing a framebuffer device in order to prevent list >

Re: [Intel-gfx] [PATCH v2 1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs

On Tue, Nov 29, 2016 at 7:02 AM, Chris Wilson wrote: > The fb_helper->connector_count is modified when a new connector is > constructed following a hotplug event (e.g. DP-MST). This causes trouble > for drm_setup_crtcs() and friends that assume that fb_helper is >

Re: [Intel-gfx] [PATCH v2 2/3] drm: Pull together probe + setup for drm_fb_helper

On Tue, Nov 29, 2016 at 3:29 PM, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 12:02:16PM +, Chris Wilson wrote: >> drm_fb_helper_probe_connector_modes() is always called before >> drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a >> small bit of code

[Intel-gfx] [PATCH i-g-t] lib/igt_aux.h: Cast is confusing old gcc

I noticed in some machines igt compilation was breaking after igt_dummyload was introduced. I don't know exactly why, but it seems this cast seems to let old gcc a bit confused. Without the cast everything works properly. Compilation Error log: CC igt_dummyload.lo In file included from

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move priority bumping for flips earlier

On 28/11/2016 14:36, Chris Wilson wrote: David found another issue with priority bumping from mmioflips, where we are accessing the requests concurrently to them being retired and freed. Whilst we are skipping the dependency if has been submitted, that is not sufficient to stop the dependency

Re: [Intel-gfx] [PATCH 2/2] Revert "drm/i915/execlists: Use a local lock for dfs_link access"

On 28/11/2016 14:36, Chris Wilson wrote: This reverts commit 27745e829a5c ("drm/i915/execlists: Use a local lock for dfs_link access") as the struct_mutex was required to prevent concurrent retiring and freeing, now restored in the previous patch. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Moving scaler numbers to runtime init (rev5)

== Series Details == Series: drm/i915: Moving scaler numbers to runtime init (rev5) URL : https://patchwork.freedesktop.org/series/15726/ State : warning == Summary == Series 15726v5 drm/i915: Moving scaler numbers to runtime init

Re: [Intel-gfx] [PATCH 2/3] drm/i915: abstract ddi being audio enabled

On Mon, 28 Nov 2016, libin.y...@intel.com wrote: > From: Libin Yang > > Prepare for using the same code for judging ddi being audio enabled. > No functional changes. > > Signed-off-by: Libin Yang > Signed-off-by: Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH v6 8/8] drm/i915/gen9: WM memory bandwidth related workaround

Mahesh Kumar schreef op di 29-11-2016 om 11:12 [+0530]: > Hi, > > > On Thursday 24 November 2016 06:21 PM, Lankhorst, Maarten wrote: > > > > Mahesh Kumar schreef op do 24-11-2016 om 09:31 [+0530]: > > > > > > This patch implemnets Workariunds related to display arbitrated > > > memory > > >

[Intel-gfx] [PATCH] drm/i915: Convert vm->dev backpointer to vm->i915

99% of the time we access i915_address_space->dev we want the i915 device and not the drm device, so let's store the drm_i915_private backpointer instead. The only real complication here are the inlines in i915_vma.h where drm_i915_private is not yet defined and so we have to choose an alternate

[Intel-gfx] [PULL] drm-intel-next

Hi Dave, Final 4.10 updates: - fine-tune fb flushing and tracking (Chris Wilson) - refactor state check dumper code for more conciseness (Tvrtko) - roll out dev_priv all over the place (Tvrkto) - finally remove __i915__ magic macro (Tvrtko) - more gvt bugfixes (Zhenyu) - better opregion CADL

Re: [Intel-gfx] [PATCH] drm/i915: fix compilation warnings on maybe uninitialized pointers

On Mon, Nov 28, 2016 at 06:43:19PM -0500, Jérémy Lefaure wrote: > Two warnings are produced by gcc (tested with gcc 6.2.1): > > drivers/gpu/drm/i915/intel_csr.c: In function ‘csr_load_work_fn’: > drivers/gpu/drm/i915/intel_csr.c:400:5: error: ‘fw’ is used > uninitialized in this function

Re: [Intel-gfx] [PATCH v2] drm/i915: Pass dev_priv to intel_setup_outputs()

On Thu, Nov 24, 2016 at 11:44:37AM +0800, kbuild test robot wrote: > Hi Ander, > > [auto build test WARNING on drm-intel/for-linux-next] > [also build test WARNING on next-20161123] > [cannot apply to v4.9-rc6] > [if your patch is applied to the wrong git tree, please drop us a note to > help

Re: [Intel-gfx] [PATCH 3/3] drm/i915: enable dp mst audio

On Mon, 28 Nov 2016, libin.y...@intel.com wrote: > From: Libin Yang > > This patch adds support for DP MST audio in i915. > > Enable audio codec when DP MST is enabled if has_audio flag is set. > Disable audio codec when DP MST is disabled if has_audio flag is set. > >

Re: [Intel-gfx] [PATCH] drm/i915: Convert vm->dev backpointer to vm->i915

On ti, 2016-11-29 at 09:50 +, Chris Wilson wrote: > 99% of the time we access i915_address_space->dev we want the i915 > device and not the drm device, so let's store the drm_i915_private > backpointer instead. The only real complication here are the inlines > in i915_vma.h where

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Moving scaler numbers to runtime init (rev5)

> == Series Details == > > Series: drm/i915: Moving scaler numbers to runtime init (rev5) > URL : https://patchwork.freedesktop.org/series/15726/ > State : warning > > == Summary == > > Series 15726v5 drm/i915: Moving scaler numbers to runtime init >

Re: [Intel-gfx] [PATCH] drm/i915: drop the struct_mutex when wedged or trying to reset

On Mon, Nov 28, 2016 at 01:40:17PM +0200, Jani Nikula wrote: > On Mon, 28 Nov 2016, Joonas Lahtinen wrote: > > On ma, 2016-11-28 at 10:36 +, Matthew Auld wrote: > >> We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged > >> or a reset is in

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Moving scaler numbers to runtime init (rev5)

Hi, > -Original Message- > From: Maiti, Nabendu Bikash > Sent: Tuesday, November 29, 2016 12:10 PM > To: Saarinen, Jani ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Moving scaler > numbers to runtime init

Re: [Intel-gfx] [PATCH] drm/i915: Convert vm->dev backpointer to vm->i915

On Tue, Nov 29, 2016 at 12:54:12PM +0200, Joonas Lahtinen wrote: > On ti, 2016-11-29 at 09:50 +, Chris Wilson wrote: > > 99% of the time we access i915_address_space->dev we want the i915 > > device and not the drm device, so let's store the drm_i915_private > > backpointer instead. The only

Re: [Intel-gfx] [PATCH 2/2] Revert "drm/i915/execlists: Use a local lock for dfs_link access"

On Tue, Nov 29, 2016 at 08:51:02AM +, Tvrtko Ursulin wrote: > > On 28/11/2016 14:36, Chris Wilson wrote: > >This reverts commit 27745e829a5c ("drm/i915/execlists: Use a local lock > >for dfs_link access") as the struct_mutex was required to prevent > >concurrent retiring and freeing, now

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

Hi Dave, Big thing is that drm-misc is now officially a group maintainer/committer model thing, with MAINTAINERS suitably updated. Otherwise just the usual pile of misc things all over, nothing that stands out this time around. Backmerge would also be great, since I just noticed that commit

Re: [Intel-gfx] [PULL] drm-misc-next

Hi Stephen, drm-misc has slightly moved around, new branches for you to pull in: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes git://anongit.freedesktop.org/drm/drm-misc for-linux-next It's the same aliasing branch concept as for drm-intel, to avoid trouble for you around the

Re: [Intel-gfx] [PATCH RFC v3] drm: Add a new connector atomic property for link status

On Mon, Nov 28, 2016 at 05:07:52PM -0800, Manasi Navare wrote: > On Thu, Nov 24, 2016 at 08:51:35AM +0100, Daniel Vetter wrote: > > On Wed, Nov 23, 2016 at 11:28:21PM -0800, Manasi Navare wrote: > > > This is RFC patch for adding a connector link-status property > > > and making it atomic by

Re: [Intel-gfx] [PATCH] drm/i915: fix compilation warnings on maybe uninitialized pointers

On 29/11/2016 08:56, Daniel Vetter wrote: On Mon, Nov 28, 2016 at 06:43:19PM -0500, Jérémy Lefaure wrote: Two warnings are produced by gcc (tested with gcc 6.2.1): drivers/gpu/drm/i915/intel_csr.c: In function ‘csr_load_work_fn’: drivers/gpu/drm/i915/intel_csr.c:400:5: error: ‘fw’ is used

Re: [Intel-gfx] [PATCH 1/3] drm/i915/debugfs: add dp mst info

On Mon, 28 Nov 2016, libin.y...@intel.com wrote: > From: Libin Yang > > Add the DP MST info dump in debugfs. > > Signed-off-by: Libin Yang > Signed-off-by: Dhinakaran Pandiyan > Reviewed-by: Lyude >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/5] drm/i915: Rename intel_guc.h to intel_uc.h

On Mon, Nov 28, 2016 at 02:22:18PM +0100, Arkadiusz Hiler wrote: > On Mon, Nov 28, 2016 at 12:53:27PM +, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [CI,1/5] drm/i915: Rename intel_guc.h to > > intel_uc.h > > URL :

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Moving scaler numbers to runtime init (rev5)

Its probably false alarm. Fifo underrun is not related to this patch. On 11/29/2016 2:56 PM, Saarinen, Jani wrote: == Series Details == Series: drm/i915: Moving scaler numbers to runtime init (rev5) URL : https://patchwork.freedesktop.org/series/15726/ State : warning == Summary == Series

Re: [Intel-gfx] [PATCH v3] drm/i915/perf: Wrap 64bit divides in do_div()

On Wed, Nov 23, 2016 at 3:07 PM, Chris Wilson wrote: > Just a couple of naked 64bit divides causing link errors on 32bit > builds, with: > > ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! > > v2: do_div() is only u64/u32, we need a u32/u64! > v3:

Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller

On 29/11/2016 06:55, Zhi Wang wrote: a PT page will be released if it doesn't contain any meaningful mappings during PPGTT page table shrinking. The PT entry in the upper level will be set to a scratch entry. Normally this works nicely, but in virtualization world, the PPGTT page table is

Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller

On Tue, Nov 29, 2016 at 08:48:08AM +, Tvrtko Ursulin wrote: > > On 29/11/2016 06:55, Zhi Wang wrote: > >a PT page will be released if it doesn't contain any meaningful mappings > >during PPGTT page table shrinking. The PT entry in the upper level will > >be set to a scratch entry. > > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix compilation warnings on maybe uninitialized pointers

== Series Details == Series: drm/i915: fix compilation warnings on maybe uninitialized pointers URL : https://patchwork.freedesktop.org/series/16061/ State : success == Summary == Series 16061v1 drm/i915: fix compilation warnings on maybe uninitialized pointers

Re: [Intel-gfx] [PATCH v3] Idleness DRRS test

As per discussion with Chris, on IRC following were the suggestions : - Chris has suggested an event based approach to avoid using pthreads. - Avoid using kernel-specific info like transitional delays and instead use either polling or wait-for-event approach. Need to focus on user-observable

Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

On Tue, Nov 29, 2016 at 09:40:29PM +0200, Imre Deak wrote: > For LSPCON initialization during system resume we need AUX > functionality, but we call the corresponding encoder reset hook with all > interrupts disabled. Without interrupts we'll do a poll-wait for AUX > transfer completions, which

Re: [Intel-gfx] [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math

On Mon, Nov 14, 2016 at 01:50:20PM -0800, Dhinakaran Pandiyan wrote: > We store DP link rates as link clock frequencies in kHz, just like all > other clock values. But, DP link rates in the DP Spec. are expressed in > Gbps/lane, which seems to have led to some confusion. > > E.g., for HBR2 > Max.

Re: [Intel-gfx] [PATCH v2 2/3] drm: Pull together probe + setup for drm_fb_helper

On Tue, Nov 29, 2016 at 12:02:16PM +, Chris Wilson wrote: > drm_fb_helper_probe_connector_modes() is always called before > drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a > small bit of code compaction. > > Signed-off-by: Chris Wilson >

Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

On Tue, 2016-11-29 at 22:27 +0200, Ville Syrjälä wrote: > On Tue, Nov 29, 2016 at 10:14:23PM +0200, Imre Deak wrote: > > On Tue, 2016-11-29 at 21:55 +0200, Ville Syrjälä wrote: > > > On Tue, Nov 29, 2016 at 09:40:29PM +0200, Imre Deak wrote: > > > > For LSPCON initialization during system resume

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/perf: More documentation hooked to i915.rst

> == Series Details == > > Series: drm/i915/perf: More documentation hooked to i915.rst > URL : https://patchwork.freedesktop.org/series/16114/ > State : warning > > == Summary == > > Series 16114v1 drm/i915/perf: More documentation hooked to i915.rst >

[Intel-gfx] [PATCH 3/3] assembler: RSQ is a math function

Signed-off-by: Kristian H. Kristensen --- assembler/gram.y | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/assembler/gram.y b/assembler/gram.y index f370dfa..d6f4a19 100644 --- a/assembler/gram.y +++ b/assembler/gram.y @@ -1985,7 +1985,7 @@

[Intel-gfx] [PATCH 1/3] assembler: Fix assert when setting 3src sources

We need to map the type to the 3src encoding before comparing to insn->bits1.da3src.src_reg_type, which is 3src encoded. Signed-off-by: Kristian H. Kristensen --- assembler/brw_eu_emit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 2/3] assembler: Set 3src options before sources

Setting the 3src sources will assert align16, but that doesn't get set until we call set_instruction_options(). Call that before setting sources. Signed-off-by: Kristian H. Kristensen --- assembler/gram.y | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_psr_init() kerneldoc

Hi Ander, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.9-rc7 next-20161129] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ander-Conselvan-de-Oliveira

Re: [Intel-gfx] [PATCH 1/3] drm/i915/debugfs: add dp mst info

>-Original Message- >From: Vivi, Rodrigo >Sent: Wednesday, November 30, 2016 1:22 AM >To: jani.nik...@linux.intel.com >Cc: ville.syrj...@linux.intel.com; intel-gfx@lists.freedesktop.org; Yang, Libin >; Vetter, Daniel ; >ti...@suse.de;

[Intel-gfx] [PATCH v2] drm/i915: Move the release of PT page to the upper caller

a PT page will be released if it doesn't contain any meaningful mappings during PPGTT page table shrinking. The PT entry in the upper level will be set to a scratch entry. Normally this works nicely, but in virtualization world, the PPGTT page table is tracked by hypervisor. Releasing the PT page

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/gen9: Fix PCODE polling during SAGV disabling

One tiny nitpick below On Mon, 2016-11-28 at 13:12 +0200, Imre Deak wrote: > According to the previous patch, it's possible atm that we call > intel_do_sagv_disable() only once during the 1ms period and time out > if > that call fails. As opposed to this the spec says that we need to > keep >

[Intel-gfx] [PATCH] drm/i915: Fix intel_psr_init() kerneldoc

In commit c39055b072f8 ("drm/i915: Pass dev_priv to intel_setup_outputs()"), I forgot to update the kerneldoc for intel_psr_init() init, leading to warnings when building the documentation: drivers/gpu/drm/i915/intel_psr.c:822: warning: No description found for parameter 'dev_priv'

Re: [Intel-gfx] [PATCH v6 8/8] drm/i915/gen9: WM memory bandwidth related workaround

On Tuesday 29 November 2016 03:16 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op di 29-11-2016 om 11:12 [+0530]: Hi, On Thursday 24 November 2016 06:21 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op do 24-11-2016 om 09:31 [+0530]: This patch implemnets Workariunds related to

[Intel-gfx] [PATCH v2 5/6] drm/i915/guc: Keep the execbuf client allocated across reset

In order to avoid some complexity in trying to reconstruct the workqueues across reset, remember them instead. The issue comes when we have to handle a reset between request allocation and submission, the request has reserved space in the wq, but is not in any list so we fail to restore the

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Trim i915_guc_info() stack usage

On 29/11/2016 12:10, Chris Wilson wrote: i915_guc_info() (part of debugfs output) tries to avoid holding struct_mutex for a long period by copying onto the stack. This causes a warning that the stack frame is massive, so stop doing that. We can even forgo holding the struct_mutex here as that

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

On Tue, Nov 29, 2016 at 01:38:58PM +0100, Hans de Goede wrote: > Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. > > Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") > Cc: Jani Nikula > Cc: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote: > Looking at the ADF code from the Android kernel sources for a > cherrytrail tablet I noticed that it is calling the > MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. > > Until commit b1cb1bd29189 ("drm/i915/dsi: update

[Intel-gfx] [PATCH v2 3/3] drm: Protect fb_helper list manipulation with a mutex

Though we only walk the kernel_fb_helper_list inside a panic (or single thread debugging), we still need to protect the list manipulation on creating/removing a framebuffer device in order to prevent list corruption. Signed-off-by: Chris Wilson Reviewed-by: Daniel

[Intel-gfx] [PATCH v2 1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs

The fb_helper->connector_count is modified when a new connector is constructed following a hotplug event (e.g. DP-MST). This causes trouble for drm_setup_crtcs() and friends that assume that fb_helper is constant: [ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at

[Intel-gfx] [PATCH v2 2/3] drm: Pull together probe + setup for drm_fb_helper

drm_fb_helper_probe_connector_modes() is always called before drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a small bit of code compaction. Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter ---

[Intel-gfx] [PATCH v2 4/6] drm/i915/guc: Initialise doorbell cookie to matching value

Set the initial value of the doorbell cookie from the client. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_guc_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH v2 2/6] drm/i915: Trim i915_guc_info() stack usage

i915_guc_info() (part of debugfs output) tries to avoid holding struct_mutex for a long period by copying onto the stack. This causes a warning that the stack frame is massive, so stop doing that. We can even forgo holding the struct_mutex here as that doesn't serialise the values being read (and

[Intel-gfx] [PATCH v2 1/6] HAX drm/i915: Enable guc submission

--- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 0e280fbd52f1..ef1e9921a2af 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++

[Intel-gfx] [PATCH v2 6/6] drm/i915/guc: Split hw submission for replay after GPU reset

Something I missed before sending off the partial series was that the non-scheduler guc reset path was broken (in the full series, this is pushed to the execlists reset handler). The issue is that after a reset, we have to refill the GuC workqueues, which we do by resubmitting the requests.

[Intel-gfx] [PATCH v2 3/6] drm/i915/guc: Rename client->cookie to match use

The client->cookie is a shadow of the doorbell->cookie value, so rename it to indicate its association with the doorbell, like the doorbell id and offset. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline

[Intel-gfx] [PATCH 2/2] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") Cc: Jani Nikula Cc: Ville Syrjälä Signed-off-by: Hans de Goede ---

[Intel-gfx] [PATCH] drm/i915: Fix tracepoint compilation

drivers/gpu/drm/i915/./i915_trace.h: In function ‘trace_event_raw_event_i915_gem_evict’: drivers/gpu/drm/i915/./i915_trace.h:409:24: error: ‘struct i915_address_space’ has no member named ‘dev’ __entry->dev = vm->dev->primary->index; A couple of macros missed in the s/vm->dev/vm->i915/

Re: [Intel-gfx] [PATCH] drm/i915: Fix tracepoint compilation

On Tue, Nov 29, 2016 at 12:42:05PM +, Chris Wilson wrote: > drivers/gpu/drm/i915/./i915_trace.h: In function > ‘trace_event_raw_event_i915_gem_evict’: > drivers/gpu/drm/i915/./i915_trace.h:409:24: error: ‘struct > i915_address_space’ has no member named ‘dev’ >__entry->dev =

[Intel-gfx] [drm-intel:drm-intel-next-queued 1/3] drivers/gpu/drm/i915/./i915_trace.h:409:24: error: 'struct i915_address_space' has no member named 'dev'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: c6385c947f4d1526d823a16ea25daa93d2897997 commit: 49d73912cbfcaa3eba109a44ee71200c12fa27ef [1/3] drm/i915: Convert vm->dev backpointer to vm->i915 config: i386-defconfig (attached as .config) compiler: gcc-6 (Debian

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

Hi, Thanks for the quick reply. On 29-11-16 13:48, Ville Syrjälä wrote: On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote: Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: VLV/CHV atomic wm prep work

== Series Details == Series: drm/i915: VLV/CHV atomic wm prep work URL : https://patchwork.freedesktop.org/series/16049/ State : success == Summary == Series 16049v1 drm/i915: VLV/CHV atomic wm prep work https://patchwork.freedesktop.org/api/1.0/series/16049/revisions/1/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH] drm/i915: Fix tracepoint compilation

On Tue, Nov 29, 2016 at 12:42:05PM +, Chris Wilson wrote: > drivers/gpu/drm/i915/./i915_trace.h: In function > ‘trace_event_raw_event_i915_gem_evict’: > drivers/gpu/drm/i915/./i915_trace.h:409:24: error: ‘struct > i915_address_space’ has no member named ‘dev’ >__entry->dev =

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

On Tue, Nov 29, 2016 at 02:06:20PM +0100, Hans de Goede wrote: > Hi, > > Thanks for the quick reply. > > On 29-11-16 13:48, Ville Syrjälä wrote: > > On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote: > >> Looking at the ADF code from the Android kernel sources for a > >> cherrytrail

[Intel-gfx] [PATCH] drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

From: Ville Syrjälä Looks like we're only initializing dev_priv->atomic_cdclk_freq at resume and commit times, not at init time. Let's do that as well. We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in hsw_compute_linetime_wm() on account of populating

Re: [Intel-gfx] [PATCH] drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

On 29 November 2016 at 14:13, wrote: > From: Ville Syrjälä > > Looks like we're only initializing dev_priv->atomic_cdclk_freq > at resume and commit times, not at init time. Let's do that as > well. > > We're now hitting the

[Intel-gfx] [PATCH] drm: parse hf-vsdb

HDMI 2.0 / CEA-861-F specs define a new CEA extension data block, called hdmi-forum vendor specific data block (HF-VSDB). This block contains information about sink's support for HDMI 2.0 compliant features. These features are: - Deep color YUV 420 support and BPC - 3D flags for -

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: Fix CRC based atomic correctness test

Fixes issues on kms_plane_multiple i-g-t test found when running CI tests v1: - don't use tiling for cursor plane (Ville) - for y/yf tiling check that the platform is at least GEN9 (Ville) Cc: Ville Syrjala Cc: Maarten Lankhorst

[Intel-gfx] [PATCH] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

For LSPCON initialization during system resume we need AUX functionality, but we call the corresponding encoder reset hook with all interrupts disabled. Without interrupts we'll do a poll-wait for AUX transfer completions, which adds a significant delay if the transfers timeout/need to be retried

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs

== Series Details == Series: series starting with [v2,1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs URL : https://patchwork.freedesktop.org/series/16094/ State : success == Summary == Series 16094v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pass dev_priv to intel_setup_outputs() (rev3)

== Series Details == Series: drm/i915: Pass dev_priv to intel_setup_outputs() (rev3) URL : https://patchwork.freedesktop.org/series/15820/ State : success == Summary == Series 15820v3 drm/i915: Pass dev_priv to intel_setup_outputs()

Re: [Intel-gfx] [PATCH v6 8/8] drm/i915/gen9: WM memory bandwidth related workaround

Mahesh Kumar schreef op di 29-11-2016 om 19:17 [+0530]: > > On Tuesday 29 November 2016 03:16 PM, Lankhorst, Maarten wrote: > > > > Mahesh Kumar schreef op di 29-11-2016 om 11:12 [+0530]: > > > > > > Hi, > > > > > > > > > On Thursday 24 November 2016 06:21 PM, Lankhorst, Maarten wrote: > > >

[Intel-gfx] [PATCH] dim: Add status command

Useful with our branch proliferation to make sure nothing is stuck (we now also have drm-misc-next/-next-fixes/-fixes). v2: Gracefully handle if some remotes arent' there. Acked-by: seanp...@chromium.org Signed-off-by: Daniel Vetter --- dim | 22

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

On Mon, Nov 28, 2016 at 7:59 PM, Manasi Navare wrote: > On Wed, Nov 23, 2016 at 09:09:28AM +0100, Daniel Vetter wrote: >> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote: >> > On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare >> >

[Intel-gfx] [PATCH 3/3] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[Intel-gfx] [PATCH 2/3] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure and limits the max link_rate and lane_count values to these

  1   2   >