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

On Thu, 2016-11-10 at 15:55 -0800, Manasi Navare wrote: > On Wed, Nov 09, 2016 at 09:32:29PM -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

Re: [Intel-gfx] [PATCH v2] drm/i915/audio: fix hdmi audio noise issue

Hi Jani, > -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Thursday, November 10, 2016 6:37 PM > To: Yang, Libin ; intel-gfx@lists.freedesktop.org; > ville.syrj...@linux.intel.com; Vetter, Daniel ; >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

== Series Details == Series: drm/i915: Only poll DW3_A when init DDI PHY for ports B and C. URL : https://patchwork.freedesktop.org/series/15139/ State : failure == Summary == Series 15139v1 drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

Re: [Intel-gfx] [PATCH 09/15] drm/i915/glk: Implement Geminilake DDI init sequence

Reviewed-by: Rodrigo Vivi On Thu, Nov 10, 2016 at 05:23:14PM +0200, Ander Conselvan de Oliveira wrote: > Implement the DDI initsequence and add information about the different > phys in GLK. > > v2: Rebase on the move of phys to be power wells. > > v3: Rebase on

Re: [Intel-gfx] [PATCH] make intel_chipset.h public

Yes, I am interested in the generation. Since DRM_IOCTL_I915_GETPARAM returns the pci_id, a common place to get the generation would be nice. Intel folks, where do you think would be the best place to put this (libdrm_intel or the kernel)?? On Thu, Nov 10, 2016 at 10:47 AM, Emil Velikov

[Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

According to Bspec we need to "Poll for PORT_REF_DW3_A grc_done == 1b" only on ports B and C initialization sequence when copying rcomp from port A. So let's follow the spec and only poll for that case and not on every port A initialization. Cc: Imre Deak Cc: Ander

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

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/15135/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_lvds.o CC [M] drivers/gpu/drm/i915/intel_panel.o CC [M] drivers/gpu/drm/i915/intel_sdvo.o LD [M]

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

These patches add HuC loading support. The userspace patches that check for a fully loaded HuC firmware and use it can be found at: https://lists.freedesktop.org/archives/libva/2016-September/004554.html https://lists.freedesktop.org/archives/libva/2016-September/004555.html v2: rebased. v3:

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

From: Peter Antoine 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.

[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 Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc_loader.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git

[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 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. Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc_loader.c | 13 - 1 file changed,

[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. Tested-by: Xiang Haihao Signed-off-by: Anusha Srivatsa

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

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

On Wed, Nov 09, 2016 at 09:32:29PM -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 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote: > Not validating the the mode rate against link rate results not pruning > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not > support 4k @ 60Hz. But, we do not reject this mode currently. > > So, make use of

Re: [Intel-gfx] [PATCH 02/15] drm/i915/glk: Introduce Geminilake platform definition

On Thu, Nov 10, 2016 at 05:23:07PM +0200, Ander Conselvan de Oliveira wrote: > Geminilake is an Intel® Processor containing Intel® HD Graphics > following Broxton. > > Let's start by adding the platform definition. PCI IDs and plaform > specific code will follow. > > v2: Rebase (don't allow dev

Re: [Intel-gfx] [PATCH v3 04/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.

On Thu, Nov 10, 2016 at 07:59:05AM +0100, Maarten Lankhorst wrote: > Op 10-11-16 om 01:52 schreef Matt Roper: > > On Tue, Nov 08, 2016 at 01:55:35PM +0100, Maarten Lankhorst wrote: > >> This member is only used in skl_update_crtcs now. It's easy to remove it > >> by keeping track of which ddb

Re: [Intel-gfx] [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell

On 11/09, Robert Bragg wrote: > Signed-off-by: Robert Bragg > --- > tests/Makefile.sources |1 + > tests/perf.c | 2220 > > 2 files changed, 2221 insertions(+) > create mode 100644 tests/perf.c > > diff --git

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

On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote: > @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct intel_dp > *intel_dp, > return false; > } > > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work) > +{ > + struct intel_connector

Re: [Intel-gfx] [PULL] GVT-g KVMGT framework

On Thu, Nov 10, 2016 at 05:47:14PM +0800, Zhenyu Wang wrote: > > Hi, > > This is initial integration work to include KVMGT support which > base on MPT(Mediated Passthrough) interface for GVT-g device model. > Also include vGPU type definitions which means vGPU creation will > be type based to be

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

Adding Harry and Tony from our display team to review. > -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Thursday, November 10, 2016 1:20 PM > To: Manasi Navare; dri-de...@lists.freedesktop.org; intel- > g...@lists.freedesktop.org > Cc: Dave Airlie;

Re: [Intel-gfx] [PATCH] make intel_chipset.h public

On 28 October 2016 at 04:38, Gurchetan Singh wrote: > This file has useful information regarding the pci-id --> gen > conversion. The gen determines which scanout formats a chipset > supports (for example, the SKL display engine can scanout Y-tiled > formats). This

[Intel-gfx] [PATCH] intel: Add Geminilake PCI IDs

From: Ben Widawsky Signed-off-by: Ben Widawsky --- intel/intel_chipset.h | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 514f659..41fc0da 100644 ---

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

On Thu, 10 Nov 2016, Manasi Navare wrote: > Link training failure is handled by lowering the link rate first > until it reaches the minimum and keeping the lane count maximum > and then lowering the lane count until it reaches minimim. These > fallback values are saved

[Intel-gfx] [PATCH i-g-t] lib: substitute cxt BAN_PERIOD with BANNABLE

Context BAN_PERIOD will get depracated so subsitute it with BANNABLE property. Make ctx param test to accept both variants for now until kernel changes have landed, to not break BAT. Cc: Chris Wilson Signed-off-by: Mika Kuoppala ---

[Intel-gfx] [PATCH] drm/i915: Only wait upon the execution timeline when unlocked

In order to walk the list of all timelines, we currently require the struct_mutex. We are sometimes called prior to the struct_mutex being taken by the caller (i.e !I915_WAIT_LOCKED) in which case we can only trust the global execution timelines (as these are owned by the device). This means in

Re: [Intel-gfx] [PATCH 05/15] drm/i915/glk: Reuse broxton code for geminilake

On Thu, Nov 10, 2016 at 05:23:10PM +0200, Ander Conselvan de Oliveira wrote: > Geminilake is mostly backwards compatible with broxton, so change most > of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the > platforms will be implemented in follow-up patches. > > v2: Don't reuse

Re: [Intel-gfx] [PATCH 03/15] drm/i915/glk: Add Geminilake PCI IDs

Reviewed-by: Rodrigo Vivi On Thu, Nov 10, 2016 at 05:23:08PM +0200, Ander Conselvan de Oliveira wrote: > v2: Add new 0x3185 ID. (Joonas) > Signed-off-by: Ander Conselvan de Oliveira > > --- > drivers/gpu/drm/i915/i915_pci.c | 1

Re: [Intel-gfx] [PATCH 02/15] drm/i915/glk: Introduce Geminilake platform definition

Yep, it is probably better to merge Jani patch before while no platform is using that flag, but one way or another feel free to use: Reviewed-by: Rodrigo Vivi On Thu, Nov 10, 2016 at 06:40:29PM +0200, Jani Nikula wrote: > On Thu, 10 Nov 2016, Ander Conselvan de Oliveira

Re: [Intel-gfx] [PATCH 02/15] drm/i915/glk: Introduce Geminilake platform definition

On Thu, 10 Nov 2016, Ander Conselvan de Oliveira wrote: > Geminilake is an Intel® Processor containing Intel® HD Graphics > following Broxton. > > Let's start by adding the platform definition. PCI IDs and plaform > specific code will follow. > > v2: Rebase

Re: [Intel-gfx] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio

On 11/9/16 7:19 AM, Mark Brown wrote: On Sun, Nov 06, 2016 at 11:42:31PM -0700, Pierre-Louis Bossart wrote: I am all for convergence when it makes sense but I don't see how hdmi-codec.h provides equivalent functionality for BYT/CHT with what was suggested in this patchset -derived from VED

Re: [Intel-gfx] [i-g-t PATCH v1 08/14] lib: Add igt_create_bo_with_dimensions

On 10/11/2016 13:17, Tomeu Vizoso wrote: On 1 November 2016 at 16:44, Tvrtko Ursulin wrote: Hi, On 02/03/16 14:00, Tomeu Vizoso wrote: igt_create_bo_with_dimensions() is intended to abstract differences between drivers in buffer object creation. The

Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of driver/file owner specific ops

On 11/10/2016 11:06 AM, Hugh Dickins wrote: On Fri, 4 Nov 2016, akash.g...@intel.com wrote: From: Chris Wilson This provides support for the drivers or shmem file owners to register a set of callbacks, which can be invoked from the address space operations methods

Re: [Intel-gfx] [PATCH i-g-t] lib: Pass I915_TILING_Y to the kernel if Yf or Ys

On 10/11/2016 10:15, Tomeu Vizoso wrote: GEM_SET_TILING doesn't care about Yf or Ys, so just pass Y. Signed-off-by: Tomeu Vizoso --- lib/ioctl_wrappers.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c index

[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling

== Series Details == Series: Geminilake enabling URL : https://patchwork.freedesktop.org/series/15118/ State : success == Summary == Series 15118v1 Geminilake enabling https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/1/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0

Re: [Intel-gfx] [PATCH i-g-t] lib: Pass tiling constant where that's expected

Hi, On 10/11/2016 10:12, Tomeu Vizoso wrote: We were passing in two places a framebuffer modifier constant instead of a tiling constant. Also adds igt_fb_mod_to_tiling so tests can do that by themselves. Cc: Tvrtko Ursulin Fixes: 8a1a38661f56 ("lib: Add

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On Thu, Nov 10, 2016 at 03:36:17PM +, Tvrtko Ursulin wrote: > > On 10/11/2016 15:01, Chris Wilson wrote: > >On Thu, Nov 10, 2016 at 02:45:39PM +, Tvrtko Ursulin wrote: > >> > >>On 07/11/2016 13:59, Chris Wilson wrote: > >>>+ /* Recursively bump all dependent priorities to match the new

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/6] drm/i915: Stop skipping the final clflush back to system pages

== Series Details == Series: series starting with [1/6] drm/i915: Stop skipping the final clflush back to system pages URL : https://patchwork.freedesktop.org/series/15117/ State : warning == Summary == Series 15117v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On 10/11/2016 15:01, Chris Wilson wrote: On Thu, Nov 10, 2016 at 02:45:39PM +, Tvrtko Ursulin wrote: On 07/11/2016 13:59, Chris Wilson wrote: The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any

[Intel-gfx] [PATCH 02/15] drm/i915/glk: Introduce Geminilake platform definition

Geminilake is an Intel® Processor containing Intel® HD Graphics following Broxton. Let's start by adding the platform definition. PCI IDs and plaform specific code will follow. v2: Rebase (don't allow dev to be used with the new macro). Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH 01/15] drm/i915: Create a common GEN9_LP_FEATURE.

From: Rodrigo Vivi The following LP platform inherits a lot of this platform So let's simplify here to re-use this later. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 47 ++--- 1 file

[Intel-gfx] [PATCH 06/15] drm/i915/glk: Force DDI initialization.

From: Rodrigo Vivi As for BXT, GLK doesn't support port detection through SFUSE_STRAP, so let's force DDI initialization in order to get HDMI and DP. v2: Use dev_priv instead of dev. (Tvrtko) Signed-off-by: Rodrigo Vivi Signed-off-by: Ander

[Intel-gfx] [PATCH 15/15] drm/i915/glk: Configure number of sprite planes properly

Geminilake has 4 planes (3 sprites) per pipe. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_device_info.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c

[Intel-gfx] [PATCH 14/15] drm/i915/glk: Implement core display init/uninit sequence for geminilake

The sequence is pretty much the same as broxton, except that bspec requires the AUX domains to be enabled. But since those can't be enabled before the phys are initialized, we just use the same sequence as broxton. v2: Don't manually enable AUX domains. (Ander) Signed-off-by: Ander Conselvan de

[Intel-gfx] [PATCH 12/15] drm/i915/glk: Reuse broxton's cdclk code for GLK

Geminilake has the same register layout, reference clock and programming sequence as broxton. The difference is that it doesn't support the 1.5 divider and has different ratios, but a lot of code can be shared between the two platforms. v2: Rebase (s/broxton/bxt). v3: Fix vco calculation in

[Intel-gfx] [PATCH 07/15] drm/i915/glk: Set DDI PHY lane lane optimization for Geminilake too

Geminilake uses the same lane latency optimization masks and registers as Broxton, so reuse the code with that platform too. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_ddi.c | 8 1 file changed, 4 insertions(+), 4

[Intel-gfx] [PATCH 08/15] drm/i915/glk: Add power wells for Geminilake

Geminilake has power wells are similar to SKL, but with the misc IO well being split into separate AUX IO wells. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/intel_runtime_pm.c | 114

[Intel-gfx] [PATCH 13/15] drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake

Geminilake has double wide pipes so it can output two pixels per CD clock. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 11/15] drm/i915/glk: Update Port PLL enable sequence for Geminilkae

From: Madhav Chauhan Add steps for enabling and disabling Port PLL as per bspec. Signed-off-by: Madhav Chauhan Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_reg.h | 2

[Intel-gfx] [PATCH 10/15] drm/i915/glk: Set DCC delay range 2 in PLL enable sequence

Follow the PLL enable sequence updated in bspec, which requires the DCC delay range 2 bit to be set. v2: Moved from DDI init sequence to PLL enable. Signed-off-by: Ander Conselvan De Oliveira --- drivers/gpu/drm/i915/i915_reg.h | 15 +++

[Intel-gfx] [PATCH 09/15] drm/i915/glk: Implement Geminilake DDI init sequence

Implement the DDI initsequence and add information about the different phys in GLK. v2: Rebase on the move of phys to be power wells. v3: Rebase on addition of struct bxt_ddi_phy_info. Signed-off-by: Ander Conselvan de Oliveira ---

[Intel-gfx] [PATCH 00/15] Geminilake enabling

Ander Conselvan de Oliveira (12): drm/i915/glk: Introduce Geminilake platform definition drm/i915/glk: Add Geminilake PCI IDs drm/i915/glk: Add a IS_GEN9_LP() macro drm/i915/glk: Reuse broxton code for geminilake drm/i915/glk: Set DDI PHY lane lane optimization for Geminilake too

[Intel-gfx] [PATCH 05/15] drm/i915/glk: Reuse broxton code for geminilake

Geminilake is mostly backwards compatible with broxton, so change most of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the platforms will be implemented in follow-up patches. v2: Don't reuse broxton's path in intel_update_max_cdclk(). Don't set plane count as in broxton. v3:

[Intel-gfx] [PATCH 03/15] drm/i915/glk: Add Geminilake PCI IDs

v2: Add new 0x3185 ID. (Joonas) Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_pci.c | 1 + include/drm/i915_pciids.h | 4 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_pci.c

[Intel-gfx] [PATCH 04/15] drm/i915/glk: Add a IS_GEN9_LP() macro

Broxton and Geminilake are both gen9lp platforms. To avoid adding IS_GEMINILAKE() checks everywhere alongside the IS_BROXTON() ones, add a IS_GEN9_LP() macro. v2: Rename macro parameter to dev_priv. (Joonas) Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH 4/6] drm/i915: Remove struct_mutex for destroying framebuffers

We do not need to hold struct_mutex for destroying drm_i915_gem_objects any longer, and with a little care taken over tracking obj->framebuffer_references, we can relinquish BKL locking around the destroy of intel_framebuffer. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 3/6] drm/i915: Skip clflushes for all non-page backed objects

Generalise the skip for physical and stolen objects by skipping anything we do not have a valid address inside the sg. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 5/6] drm/i915: struct_mutex is not required for allocating the framebuffer

We do not need the BKL struct_mutex in order to allocate a GEM object, nor to create the framebuffer, so resist the temptation to take the BKL willy nilly. As this changes the locking contract around internal API calls, the patch is a little larger than a plain removal of a pair of

[Intel-gfx] [PATCH 6/6] drm/i915: Drop struct_mutex around frontbuffer flushes

Since the frontbuffer has self-contained locking, it does not require us to hold the BKL struct_mutex as we send invalidate and flush messages. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_fbdev.c | 43 +++--- 1 file

[Intel-gfx] [PATCH 2/6] drm/i915: Always flush the dirty CPU cache when pinning the scanout

Currently we only clflush the scanout if it is in the CPU domain. Also flush if we have a pending CPU clflush. We also want to treat the dirtyfb path similar, and flush any pending writes there as well. v2: Only send the fb flush message if flushing the dirt on flip v3: Make flush-for-flip and

[Intel-gfx] [PATCH 1/6] drm/i915: Stop skipping the final clflush back to system pages

When we release the shmem backing storage, we make sure that the pages are coherent with the cpu cache. However, our clflush routine was skipping the flush as the object had no pages at release time. Fix this by explicitly flushing the sg_table we are decoupling. Fixes: 03ac84f1830e ("drm/i915:

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On Thu, Nov 10, 2016 at 02:45:39PM +, Tvrtko Ursulin wrote: > > On 07/11/2016 13:59, Chris Wilson wrote: > >The scheduler needs to know the dependencies of each request for the > >lifetime of the request, as it may choose to reschedule the requests at > >any time and must ensure the

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

Hi Dave, drm-intel-next-2016-11-08: - gpu idling rework for s/r (Imre) - vlv mappable scanout fix - speed up probing in resume (Lyude) - dp audio workarounds for gen9 (Dhinakaran) - more conversion to using dev_priv internally (Ville) - more gen9+ wm fixes and cleanups (Maarten) - shrinker

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On 07/11/2016 13:59, Chris Wilson wrote: The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any time and must ensure the dependency tree is not broken. This is in additional to using the fence to only

Re: [Intel-gfx] [PATCH v2] drm: Add missing mutex_destroy in drm_dev_init/release

On Thu, Nov 10, 2016 at 03:50:35PM +0200, Joonas Lahtinen wrote: > Add 3 missing mutex_destroy to drm_dev_init teardown and > drm_dev_release. > > v2: > - Also include drm_dev_release > > Signed-off-by: Joonas Lahtinen Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Defer transfer onto execution timeline to actual hw submission

On Thu, Nov 10, 2016 at 11:51:27AM +, Tvrtko Ursulin wrote: > > On 10/11/2016 11:11, Chris Wilson wrote: > >On Thu, Nov 10, 2016 at 10:43:29AM +, Tvrtko Ursulin wrote: > >> > >>On 07/11/2016 13:59, Chris Wilson wrote: > >>>Defer the transfer from the client's timeline onto the execution >

Re: [Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset

Op 10-11-16 om 11:53 schreef Ville Syrjälä: > On Wed, Nov 09, 2016 at 01:45:20PM +0100, Maarten Lankhorst wrote: >> Op 08-11-16 om 15:11 schreef Ville Syrjälä: >>> On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote: This is a hack and not needed. Use the right mask by checking

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm: Add missing mutex_destroy in drm_dev_init/release (rev2)

== Series Details == Series: series starting with [v2] drm: Add missing mutex_destroy in drm_dev_init/release (rev2) URL : https://patchwork.freedesktop.org/series/15110/ State : success == Summary == Series 15110v2 Series without cover letter

Re: [Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

On Wed, Nov 9, 2016 at 7:52 PM, Matthew Auld wrote: > On 7 November 2016 at 19:49, Robert Bragg wrote: > > The maximum OA sampling frequency is now configurable via a > > dev.i915.oa_max_sample_rate sysctl parameter. > > > > Following the

[Intel-gfx] [PATCH v2] drm: Add missing mutex_destroy in drm_dev_init/release

Add 3 missing mutex_destroy to drm_dev_init teardown and drm_dev_release. v2: - Also include drm_dev_release Signed-off-by: Joonas Lahtinen --- drivers/gpu/drm/drm_drv.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c

[Intel-gfx] [PATCH 2/2] drm/i915: Update i915_driver_load kerneldoc

Update i915_driver_load kerneldoc to match code. Cc: Chris Wilson Signed-off-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 1/2] drm: Add missing mutex_destroy in drm_dev_init

Add 3 missing mutex_destroy to drm_dev_init teardown. Signed-off-by: Joonas Lahtinen --- drivers/gpu/drm/drm_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 6efdba4..ba144b3 100644 ---

Re: [Intel-gfx] [i-g-t PATCH v1 08/14] lib: Add igt_create_bo_with_dimensions

On 1 November 2016 at 16:44, Tvrtko Ursulin wrote: > > Hi, > > > > On 02/03/16 14:00, Tomeu Vizoso wrote: >> >> igt_create_bo_with_dimensions() is intended to abstract differences >> between drivers in buffer object creation. >> >> The driver-specific ioctls will be called

Re: [Intel-gfx] [PATCH v2 09/11] drm/i915/scheduler: Support user-defined priorities

On Thu, Nov 10, 2016 at 01:02:08PM +, Tvrtko Ursulin wrote: > > On 07/11/2016 13:59, Chris Wilson wrote: > >Use a priority stored in the context as the initial value when > >submitting a request. This allows us to change the default priority on a > >per-context basis, allowing different

Re: [Intel-gfx] [PATCH v2 09/11] drm/i915/scheduler: Support user-defined priorities

On 07/11/2016 13:59, Chris Wilson wrote: Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work.

[Intel-gfx] [bug report] drm/i915/gvt: vGPU display virtualization

Hello Zhi Wang, The patch 04d348ae3f0a: "drm/i915/gvt: vGPU display virtualization" from Apr 25, 2016, leads to the following static checker warning: drivers/gpu/drm/i915/gvt/edid.c:506 intel_gvt_i2c_handle_aux_ch_write() warn: odd binop '0x0 & 0xff'

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On Thu, Nov 10, 2016 at 11:54:51AM +, Tvrtko Ursulin wrote: > > On 10/11/2016 10:55, Chris Wilson wrote: > >On Thu, Nov 10, 2016 at 10:44:44AM +, Tvrtko Ursulin wrote: > >> > >>On 08/11/2016 12:20, Chris Wilson wrote: > >>>On Mon, Nov 07, 2016 at 01:59:45PM +, Chris Wilson wrote: >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,01/11] drm/i915: Create distinct lockclasses for execution vs user timelines (rev2)

Hi, > == Series Details == > > Series: series starting with [v2,01/11] drm/i915: Create distinct lockclasses > for > execution vs user timelines (rev2) > URL : https://patchwork.freedesktop.org/series/14926/ > State : success > > == Summary == > > Series 14926v2 Series without cover letter

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for dev_priv cleanup continuation (rev3)

On to, 2016-11-10 at 09:42 +, Tvrtko Ursulin wrote: > Ready for merging and just looking for some maintainer acks. +1 on this. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On 10/11/2016 10:55, Chris Wilson wrote: On Thu, Nov 10, 2016 at 10:44:44AM +, Tvrtko Ursulin wrote: On 08/11/2016 12:20, Chris Wilson wrote: On Mon, Nov 07, 2016 at 01:59:45PM +, Chris Wilson wrote: The scheduler needs to know the dependencies of each request for the lifetime of

Re: [Intel-gfx] [PATCH v2] drm/i915: Split out i915_vma.c

On Thu, Nov 10, 2016 at 12:05:04PM +0200, Joonas Lahtinen wrote: > As a side product, had to split two other files; > - i915_gem_fence_reg.h > - i915_gem_object.h (only parts that needed immediate untanglement) > > I tried to move code in as big chunks as possible, to make review > easier.

Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Defer transfer onto execution timeline to actual hw submission

On 10/11/2016 11:11, Chris Wilson wrote: On Thu, Nov 10, 2016 at 10:43:29AM +, Tvrtko Ursulin wrote: On 07/11/2016 13:59, Chris Wilson wrote: Defer the transfer from the client's timeline onto the execution timeline from the point of readiness to the point of actual submission. For

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,01/11] drm/i915: Create distinct lockclasses for execution vs user timelines (rev2)

== Series Details == Series: series starting with [v2,01/11] drm/i915: Create distinct lockclasses for execution vs user timelines (rev2) URL : https://patchwork.freedesktop.org/series/14926/ State : success == Summary == Series 14926v2 Series without cover letter

[Intel-gfx] [PATCH v3] drm/i915: Defer transfer onto execution timeline to actual hw submission

Defer the transfer from the client's timeline onto the execution timeline from the point of readiness to the point of actual submission. For example, in execlists, a request is finally submitted to hardware when the hardware is ready, and only put onto the hardware queue when the request is ready.

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Drop unsynchronized pageflip test

On Thu, Nov 10, 2016 at 10:43:27AM +, Chris Wilson wrote: > On Thu, Nov 10, 2016 at 12:20:51PM +0200, Petri Latvala wrote: > > On Thu, Nov 10, 2016 at 08:05:19AM +, Chris Wilson wrote: > > > A raw pageflip is nonblocking and asynchronous, but > > > kms_frontbuffer_tracking persumed that it

Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Defer transfer onto execution timeline to actual hw submission

On Thu, Nov 10, 2016 at 10:43:29AM +, Tvrtko Ursulin wrote: > > On 07/11/2016 13:59, Chris Wilson wrote: > >Defer the transfer from the client's timeline onto the execution > >timeline from the point of readiness to the point of actual submission. > >For example, in execlists, a request is

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Thu, 10 Nov 2016, Laurent Pinchart wrote: > Hi Jani, > > On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote: >> On Thu, 10 Nov 2016, Laurent Pinchart wrote: >> > The issue here is that printk can't format the fourcc as a string by >> > itself. There's a bunch

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

Hi Jani, On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote: > On Thu, 10 Nov 2016, Laurent Pinchart wrote: > > On Wednesday 09 Nov 2016 16:59:31 Eric Engestrom wrote: > >> On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > >>> On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >

Re: [Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset

On Wed, Nov 09, 2016 at 01:45:20PM +0100, Maarten Lankhorst wrote: > Op 08-11-16 om 15:11 schreef Ville Syrjälä: > > On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote: > >> This is a hack and not needed. Use the right mask by checking > >> intel_state->modeset. This works for

Re: [Intel-gfx] [PATCH v2 07/11] drm/i915/scheduler: Boost priorities for flips

On 07/11/2016 13:59, Chris Wilson wrote: Boost the priority of any rendering required to show the next pageflip as we want to avoid missing the vblank by being delayed by invisible workload. We prioritise avoiding jank and jitter in the GUI over starving background tasks. v2: Descend

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On 08/11/2016 12:20, Chris Wilson wrote: On Mon, Nov 07, 2016 at 01:59:45PM +, Chris Wilson wrote: The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any time and must ensure the dependency tree is

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Drop unsynchronized pageflip test

On Thu, Nov 10, 2016 at 12:20:51PM +0200, Petri Latvala wrote: > On Thu, Nov 10, 2016 at 08:05:19AM +, Chris Wilson wrote: > > A raw pageflip is nonblocking and asynchronous, but > > kms_frontbuffer_tracking persumed that it was synchronous and completed > > before the funtion returns. It

Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Defer transfer onto execution timeline to actual hw submission

On 07/11/2016 13:59, Chris Wilson wrote: Defer the transfer from the client's timeline onto the execution timeline from the point of readiness to the point of actual submission. For example, in execlists, a request is finally submitted to hardware when the hardware is ready, and only put onto

Re: [Intel-gfx] [PATCH v2] drm/i915/audio: fix hdmi audio noise issue

On Thu, 10 Nov 2016, libin.y...@intel.com wrote: > From: Libin Yang > > Some monitors will have noise or even no sound after > applying the patch 6014ac12. > > In patch 6014ac12, it will reset the cts value to 0 for HDMI. > However, we need to disable Enable CTS or M Prog

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Thu, 10 Nov 2016, Laurent Pinchart wrote: > Hi Eric, > > On Wednesday 09 Nov 2016 16:59:31 Eric Engestrom wrote: >> On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: >> > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >> > >> Well, had to

[Intel-gfx] [PATCH i-g-t] lib: Rename tiling variables to modifier if that's what they contain

Though right now modifiers are only used to specify tiling, there are different constants for them and naming them differently should help with not mixing them. Signed-off-by: Tomeu Vizoso --- lib/igt_fb.c| 83

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Drop unsynchronized pageflip test

On Thu, Nov 10, 2016 at 08:05:19AM +, Chris Wilson wrote: > A raw pageflip is nonblocking and asynchronous, but > kms_frontbuffer_tracking persumed that it was synchronous and completed > before the funtion returns. It doesn't, so the CRC could be sampled > before the flip completed. > >

  1   2   >