[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Extend KBL platform support in GVT-g

== Series Details == Series: drm/i915/gvt: Extend KBL platform support in GVT-g URL : https://patchwork.freedesktop.org/series/27546/ State : success == Summary == Series 27546v1 drm/i915/gvt: Extend KBL platform support in GVT-g

[Intel-gfx] [PATCH v2 1/2] drm/i915: Add perf property support for context HW id

In order to support profiling for special context e.g vGPU context, we can expose vGPU context hw id and enable i915 perf property to get target context for profiling. This adds new perf property to assign target context with hw id. Jiao Pengyuan has helped to fix context reference bug in

[Intel-gfx] [PATCH v2 2/2] drm/i915/gvt: expose vGPU context hw id

This exposes vGPU context hw id in mdev sysfs which is used to do vGPU based profiling. Retrieved vGPU context hw id can be set through i915 perf ioctl to set profiling for target vGPU. Cc: Lionel Landwerlin Cc: Chris Wilson Cc: Jiao

[Intel-gfx] [PATCH v2] drm/i915/gvt: Extend KBL platform support in GVT-g

Extend KBL platform support in GVT-g. Validation tests are done on KBL server and KBL NUC. Both show the same quality. Signed-off-by: Jian Jun Chen Cc: Zhenyu Wang --- drivers/gpu/drm/i915/intel_gvt.c | 2 +- 1 file changed, 1 insertion(+), 1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Enable KBL platform support

== Series Details == Series: drm/i915/gvt: Enable KBL platform support URL : https://patchwork.freedesktop.org/series/27545/ State : success == Summary == Series 27545v1 drm/i915/gvt: Enable KBL platform support https://patchwork.freedesktop.org/api/1.0/series/27545/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Enable KBL platform support

On 2017.07.19 12:52:17 +0800, Jian Jun Chen wrote: > Enable KBL platform support in GVT-g. Validation tests > are done on KBL server and KBL NUC. Both show the same > quality. > > Signed-off-by: Jian Jun Chen > --- hmm, better to change title as this is not first try

[Intel-gfx] [PATCH] drm/i915/gvt: Enable KBL platform support

Enable KBL platform support in GVT-g. Validation tests are done on KBL server and KBL NUC. Both show the same quality. Signed-off-by: Jian Jun Chen --- drivers/gpu/drm/i915/intel_gvt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation

On 2017.07.19 00:55:19 +, Zhang, Tina wrote: > > > > Of course we need that modifier for complete format info. Don't just think > > for > > i915 usage, there's possible modifier for other vendor driver, and it's > > required > > for e.g ADDFB2 in drm kms. Pls add it back in next version. >

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

Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/vboxvideo/vbox_drv.c:235:2: error: unknown field 'set_busid' specified in initializer .set_busid = drm_pci_set_busid, ^ drivers/staging/vboxvideo/vbox_drv.c:235:15:

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/i915_reg.h between commit: c379b897ba1a ("drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming") from Linus' tree and commit: 5a8dd2af31a7 ("drm/i915/cnl: Fix RMW on ddi

Re: [Intel-gfx] [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation

> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Zhenyu Wang > Sent: Monday, July 17, 2017 10:27 AM > To: Zhang, Tina > Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; >

Re: [Intel-gfx] [PATCH v10] vfio: ABI for mdev display dma-buf operation

> -Original Message- > From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Monday, July 17, 2017 7:03 PM > To: Kirti Wankhede ; Zhang, Tina > ; Tian, Kevin ; linux- > ker...@vger.kernel.org;

Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

Daniel Vetter writes: > There's a bunch of reasons why I think we should formalize and enforce > our review rules for igt patches: > > - We have a lot of new engineers joining and review helps enormously > with mentoring and learning. But right now only patches from >

[Intel-gfx] [PATCH v4 2/4] drm/i915/psr: Account for sink CRC raciness on some panels

According to the eDP spec, when the count field in TEST_SINK_MISC increments then the six bytes of sink CRC information in the DPCD should be valid. Unfortunately, this doesn't seem to be the case on some panels, and as a result we get some incorrect and inconsistent values from the sink CRC DPCD

[Intel-gfx] [PATCH v4 4/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.

Some fixed resolution panels actually support more than one mode, with the only thing different being the refresh rate. Having this alternate mode available to us is desirable, because it allows us to test PSR on panels whose setup time at the preferred mode is too long. With this patch we allow

[Intel-gfx] [PATCH v4 1/4] drm/i915/psr: Clean-up intel_enable_source_psr1()

On SKL+ there is a bit in SRD_CTL that software is not supposed to modify, but we currently clobber that bit when we enable PSR. In order to preserve the value of that bit, go ahead and read SRD_CTL and do a field-wise setting of the various bits that we need to initialize before writing the

[Intel-gfx] [PATCH v4 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP

This set of changes has some history to them. There were several attempts to add what was called "fast link training" to i915, which actually wasn't fast link training as per the DP spec. These changes were 5fa836a9d859 ("drm/i915: DP link training optimization") 4e96c97742f4 ("drm/i915: eDP

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

Quoting Paul Kocialkowski (2017-07-18 16:16:26) > It may occur that a hotplug uevent is detected at resume, even though it > does not indicate that an actual hotplug happened. This is the case when > link training fails on any other connector. > > There is currently no way to distinguish what

Re: [Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

On Tue, 2017-07-18 at 19:35 +0100, Chris Wilson wrote: > Quoting Dhinakaran Pandiyan (2017-07-18 19:28:00) > > INTEL_GEN() appears to be the new way of doing these platform checks, so > > convert this i915_irq.c too. > > > > Signed-off-by: Dhinakaran Pandiyan >

Re: [Intel-gfx] [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

Hi Daniel, El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit: > On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote: > > The current code uses in some instances enum transcoder for PCH > > transcoders and enum pipe in others. This is error prone and clang > > raises

Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

On Tue, Jul 18, 2017 at 10:34 PM, Lionel Landwerlin wrote: > Acked-by: Lionel Landwerlin > > I assume review cannot be provided by someone who doesn't already contribute > or has a number of patches in already. > > What's the criteria

Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

Acked-by: Lionel Landwerlin I assume review cannot be provided by someone who doesn't already contribute or has a number of patches in already. What's the criteria to become a reviewer? Is there is going to be a list of people to go to for review? - Lionel On

Re: [Intel-gfx] [PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result

For the whole series Reviewed-by: Lyude will push in just a sec On Tue, 2017-07-18 at 18:16 +0300, Paul Kocialkowski wrote: > This patch introduces a workaround for a case where a uevent is > issued > by the kernel because of DP link training failing on a connector >

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

On Wed, Jul 19, 2017 at 12:46:37AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 7/18/2017 11:42 PM, Imre Deak wrote: > > On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote: > > > To get HDMI YCBCR420 output, the PIPEMISC register should be > > > programmed to: > >

[Intel-gfx] drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

Hello there, drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean expression with an integer other than 0 or 1. Source code is else if ((ddb_allocation && ddb_allocation / fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 1) Regards David

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

Regards Shashank On 7/18/2017 11:42 PM, Imre Deak wrote: On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote: To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in

Re: [Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result

On Tue, Jul 18, 2017 at 05:25:36PM +0300, Paul Kocialkowski wrote: > This adds the connector name when printing a debug message about the DP > link training result. It is useful to figure out what connector is > failing when multiple DP connectors are used. > Thanks for the patch, this does make

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable FBC for non X-tiled FBs (rev5)

== Series Details == Series: drm/i915: Enable FBC for non X-tiled FBs (rev5) URL : https://patchwork.freedesktop.org/series/21264/ State : success == Summary == Series 21264v5 drm/i915: Enable FBC for non X-tiled FBs https://patchwork.freedesktop.org/api/1.0/series/21264/revisions/5/mbox/

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"

May be the older panel might not work well with this feature. David/Jani, what do you think about adding check that the panel is eDP 1.4 or later in the heuristic? diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c index

Re: [Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result

On Tue, 2017-07-18 at 17:25 +0300, Paul Kocialkowski wrote: > This adds the connector name when printing a debug message about the DP > link training result. It is useful to figure out what connector is > failing when multiple DP connectors are used. > > Signed-off-by: Paul Kocialkowski

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

On Tue, Jul 18, 2017 at 2:42 PM, Sean Paul wrote: > Hi Dave, > Here's the first -misc-next pull for 4.13 err, 4.14. > , definitely the largest one I've > sent to you. There's nothing too disruptive, a bunch of clean-up series which > tidy up atomic macros, return value

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

== Series Details == Series: drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq URL : https://patchwork.freedesktop.org/series/27510/ State : success == Summary == Series 27510v1 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

[Intel-gfx] [PATCH v5] drm/i915: Fix FBC cfb stride programming for non X-tiled FB

When FBC is enabled for linear, legacy Y-tiled and Yf-tiled surfaces on gen9, the cfb stride must be programmed by SW as cfb_stride = ceiling[(at least plane width in pixels)/ (32 * compression limit factor)] * 8 v2: Minor fix for a build error v3: Fixed subject, register

Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

Quoting Tvrtko Ursulin (2017-07-18 15:36:16) > From: Tvrtko Ursulin > > Enables other i915 components to enable and disable > the facility as needed. > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/intel_engine_cs.c | 53 >

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

Hi Dave, Here's the first -misc-next pull for 4.13, definitely the largest one I've sent to you. There's nothing too disruptive, a bunch of clean-up series which tidy up atomic macros, return value fixes, etc. New functionality includes 2 new dsi bridge drivers, async atomic commits, YCBCR 4:2:0

Re: [Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

Quoting Dhinakaran Pandiyan (2017-07-18 19:28:00) > INTEL_GEN() appears to be the new way of doing these platform checks, so > convert this i915_irq.c too. > > Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Chris Wilson -Chris

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

Quoting Lionel Landwerlin (2017-07-18 17:50:42) > static struct drm_driver driver = { > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 2b824f8875c4..607484737f3d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@

[Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq

INTEL_GEN() appears to be the new way of doing these platform checks, so convert this i915_irq.c too. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/i915_irq.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff

Re: [Intel-gfx] [PATCH v4 i-g-t] igt/perf: add tests to verify create/destroy userspace configs

Quoting Lionel Landwerlin (2017-07-18 18:18:52) > v2: Add tests regarding removing configs (Matthew) > Add tests regarding adding/removing configs without permissions > (Matthew) > > v3: Add some flex registers (Matthew) > > v4: memset oa_config to 0 (Lionel) > Change error code for

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote: > To get HDMI YCBCR420 output, the PIPEMISC register should be > programmed to: > - Generate YCBCR output (bit 11) > - In case of YCBCR420 outputs, it should be programmed in full > blend mode to use the scaler in 5x3 ratio (bits

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Attach a stub pm_domain

== Series Details == Series: drm/i915/selftests: Attach a stub pm_domain URL : https://patchwork.freedesktop.org/series/27505/ State : success == Summary == Series 27505v1 drm/i915/selftests: Attach a stub pm_domain https://patchwork.freedesktop.org/api/1.0/series/27505/revisions/1/mbox/

[Intel-gfx] [PATCH v2] drm/i915: Only free the oldest stale object before a fresh allocation

Inspired by Tvrtko's critique of the reaping of the stale contexts before allocating a new one, also limit the freed object reaping to the oldest stale object before allocating a fresh object. Unlike contexts, objects may have radically different sizes of backing storage, but similar to contexts,

[Intel-gfx] [PATCH] drm/i915/selftests: Attach a stub pm_domain

Supply a pm_domain and its ops for our mock GEM device so that device runtime pm doesn't complain even though we only want to mark it permanently active! Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 22 +- 1

[Intel-gfx] [PATCH v4 i-g-t] igt/perf: add tests to verify create/destroy userspace configs

v2: Add tests regarding removing configs (Matthew) Add tests regarding adding/removing configs without permissions (Matthew) v3: Add some flex registers (Matthew) v4: memset oa_config to 0 (Lionel) Change error code for removing unexisting config EINVAL->ENOENT (Lionel)

[Intel-gfx] [PATCH i-g-t v3 3/5] lib/igt_draw: add support for Y tiling

From: Paulo Zanoni From: Paulo Zanoni Most of the patch is to change the tile/untile functions so they can work with Y-major tiling. v2: (Praveen) No skipping on BLT for Y-tile now as we have a fix for that. Reviewed-by: Praveen Paneri

[Intel-gfx] [PATCH i-g-t v3 0/5] Add Y-tiling support into IGTs

This series adds Y-tiled buffer creation support into IGT libraries and goes on to use this capability to add support into FBC tests to use Y-tiled buffers. v2: Adressed review comments v3: Included original patches from Paulo and addressed more comments Paulo Zanoni (2): lib/igt_draw: add

[Intel-gfx] [PATCH i-g-t v3 1/5] lib/igt_fb: Let others use igt_get_fb_tile_size

From: Praveen Paneri This function can be used by igt_draw to get accurate tile dimensions for all tile formats. v2: Added comments to function igt_get_fb_tile_size (Daniel) v3: Fixed errors in comments and coding style (Paulo) Signed-off-by: Praveen Paneri

[Intel-gfx] [PATCH i-g-t v3 5/5] igt/kms_fbc_crc.c : Add Y-tile tests

From: Praveen Paneri Now that we have support for Y-tiled buffers, add another iteration of tests for Y-tiled buffers. v3: - Iterate over tiling modifier instead of tiling constant (Paulo) - Improved logging and fixed indentation (Paulo) Signed-off-by: Praveen

[Intel-gfx] [PATCH i-g-t v3 4/5] tests/kms_draw_crc: add support for Y tiling

From: Paulo Zanoni From: Paulo Zanoni This is the program that's supposed to test lib/igt_draw. We just added Y tiling support for the library, so add the tests now. Reviewed-by: Praveen Paneri Signed-off-by: Paulo

[Intel-gfx] [PATCH i-g-t v3 2/5] lib/igt_fb: Add helper function for tile_to_mod

From: Praveen Paneri igt_get_fb_tile_size function takes modifer as an argument This helper function will let users to convert tiling to modifier and use igt_get_fb_tile_size() v2: Improved code comment (Paulo) Signed-off-by: Praveen Paneri

[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for loadable OA configs

== Series Details == Series: Add support for loadable OA configs URL : https://patchwork.freedesktop.org/series/27501/ State : success == Summary == Series 27501v1 Add support for loadable OA configs https://patchwork.freedesktop.org/api/1.0/series/27501/revisions/1/mbox/ Test

[Intel-gfx] [PATCH v6 0/3] Add support for loadable OA configs

Hi, Here is a v6 of this series. There are a bunch of fixes pointed out by Matthew in patch 3. There was also a pretty big issue in v5 of patch 2, I dropped some calls to function programming OACTXCONTROL on shutting down the perf stream and that triggered failures in the oa-exponents IGT test.

[Intel-gfx] [PATCH v6 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

The motivation behind this new interface is expose at runtime the creation of new OA configs which can be used as part of the i915 perf open interface. This will enable the kernel to learn new configs which may be experimental, or otherwise not part of the core set currently available through the

[Intel-gfx] [PATCH v6 1/3] drm/i915/perf: fix flex eu registers programming

We were reserving fewer dwords in the ring than necessary. Indeed we're always writing all registers once, so discard the actual number of registers given by the user and just program the whitelisted ones once. Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+") Reported-by:

Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

Acked-by: Lyude On Tue, 2017-07-18 at 18:00 +0200, Daniel Vetter wrote: > There's a bunch of reasons why I think we should formalize and > enforce > our review rules for igt patches: > > - We have a lot of new engineers joining and review helps enormously > with mentoring

[Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

There's a bunch of reasons why I think we should formalize and enforce our review rules for igt patches: - We have a lot of new engineers joining and review helps enormously with mentoring and learning. But right now only patches from contributors without commit rights are consistently

Re: [Intel-gfx] [PATCH v2 0/5] x86/io: Rely on asm-generic/io.h

On Fri, 2017-06-30 at 20:09 +0300, Andy Shevchenko wrote: > The series brings a bit of order to arch/x86/include/asm/io.h by re- > using > definitions in the generic header. > > The series has been tested on Intel Broxton hardware in 32- and 64-bit > modes. Any comments? Shall I resend this? >

Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

Quoting Tvrtko Ursulin (2017-07-18 15:36:16) > +int intel_enable_engine_stats(struct drm_i915_private *dev_priv) > +{ > + if (!i915.enable_execlists) > + return -ENODEV; > + > + mutex_lock(_engine_stats_mutex); > + if (i915_engine_stats_ref++ == 0) { > +

Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

Quoting Tvrtko Ursulin (2017-07-18 15:36:16) > +u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine) > +{ > + unsigned long flags; > + u64 total; > + > + spin_lock_irqsave(>stats.lock, flags); > + > + total = engine->stats.total; > + > + /* > +

Re: [Intel-gfx] [RFC 11/14] drm/i915: Engine busy time tracking

Quoting Tvrtko Ursulin (2017-07-18 15:36:15) > From: Tvrtko Ursulin > > Track total time requests have been executing on the hardware. > > To make this cheap it is hidden behind a static branch with the > intention that it is only enabled when there is a consumer >

[Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Catch and flush hotplug uevents after each plug

This adds calls to igt_hotplug_detected and igt_flush_hotplugs to catch and flush hotplugs from connector unplug (due to chamelium reset) and plug. These need to be intercepted so that they are not delayed and issued after resume, providing a false positive for the test result. In addition, the

[Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

It may occur that a hotplug uevent is detected at resume, even though it does not indicate that an actual hotplug happened. This is the case when link training fails on any other connector. There is currently no way to distinguish what connector caused a hotplug uevent, nor what the reason for

[Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

It may occur that a hotplug uevent is detected at resume, even though it does not indicate that an actual hotplug happened. This is the case when link training fails on any other connector. There is currently no way to distinguish what connector caused a hotplug uevent, nor what the reason for

[Intel-gfx] [PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result

This patch introduces a workaround for a case where a uevent is issued by the kernel because of DP link training failing on a connector unrelated to the current test. Since the test depends on receiving a hotplug uevent, it previously passed even though it should not have. False positives also

Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

On 07/14/2017 08:08 AM, Chris Wilson wrote: Quoting Oscar Mateo (2017-07-14 15:52:59) On 07/13/2017 03:28 PM, Rodrigo Vivi wrote: On Wed, May 3, 2017 at 9:31 AM, Chris Wilson wrote: On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote: On

[Intel-gfx] ✓ Fi.CI.BAT: success for i915 PMU and engine busy stats

== Series Details == Series: i915 PMU and engine busy stats URL : https://patchwork.freedesktop.org/series/27488/ State : success == Summary == Series 27488v1 i915 PMU and engine busy stats https://patchwork.freedesktop.org/api/1.0/series/27488/revisions/1/mbox/ Test gem_exec_flush:

Re: [Intel-gfx] [PATCH v4] drm/i915/execlists: Read the context-status buffer from the HWSP

Quoting Mika Kuoppala (2017-07-18 15:36:46) > Chris Wilson writes: > > > The engine provides a mirror of the CSB in the HWSP. If we use the > > cacheable reads from the HWSP, we can shave off a few mmio reads per > > context-switch interrupt (which are quite frequent!).

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

On 18/07/17 11:09, Matthew Auld wrote: On 07/17, Lionel Landwerlin wrote: The motivation behind this new interface is expose at runtime the creation of new OA configs which can be used as part of the i915 perf open interface. This will enable the kernel to learn new configs which may be

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Explicit the connector name for DP link training result (rev2)

== Series Details == Series: drm/i915: Explicit the connector name for DP link training result (rev2) URL : https://patchwork.freedesktop.org/series/27410/ State : success == Summary == Series 27410v2 drm/i915: Explicit the connector name for DP link training result

Re: [Intel-gfx] [PATCH v4] drm/i915/execlists: Read the context-status buffer from the HWSP

Chris Wilson writes: > The engine provides a mirror of the CSB in the HWSP. If we use the > cacheable reads from the HWSP, we can shave off a few mmio reads per > context-switch interrupt (which are quite frequent!). Just removing a > couple of mmio is not enough to

[Intel-gfx] [RFC 14/14] drm/i915/pmu: Wire up engine busy stats to PMU

From: Tvrtko Ursulin We can use engine busy stats instead of the MMIO sampling timer for better efficiency. As minimum this saves period * num_engines / sec mmio reads, and in a better case, when only engine busy samplers are active, it enables us to not kick off the

[Intel-gfx] [RFC 10/14] drm/i915: Wrap context schedule notification

From: Tvrtko Ursulin No functional change just something which will be handy in the following patch. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-)

[Intel-gfx] [RFC 09/14] drm/i915/pmu: Suspend sampling when GPU is idle

From: Tvrtko Ursulin If only a subset of events is enabled we can afford to suspend the sampling timer when the GPU is idle and so save some cycles and power. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h | 6

[Intel-gfx] [RFC 03/14] drm/i915/pmu: Add queued samplers to the PMU uAPI

From: Tvrtko Ursulin This is also partially missing in the original patch. Signed-off-by: Tvrtko Ursulin --- include/uapi/drm/i915_drm.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/uapi/drm/i915_drm.h

[Intel-gfx] [RFC 06/14] drm/i915/pmu: Only sample enabled samplers

From: Tvrtko Ursulin Save some execution time by not reading the MMIO registers for the samplers which are not enabled. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pmu.c | 49 +++-- 1 file

[Intel-gfx] [RFC 08/14] drm/i915/pmu: Expose events in sysfs

From: Tvrtko Ursulin This makes then visible to "perf list". Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pmu.c | 89 + 1 file changed, 89 insertions(+) diff --git

[Intel-gfx] [RFC 07/14] drm/i915/pmu: Add fake regs

From: Tvrtko Ursulin Without this I can get a null ptr deref when trying to access our events with perf. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pmu.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [RFC 04/14] drm/i915/pmu: Decouple uAPI engine ids

From: Tvrtko Ursulin As elsewhere in the code we have to decouple the binary engine identifiers for easier maintenance. Also the sampler mask was incorrect in the timer callback. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection

From: Tvrtko Ursulin Enables other i915 components to enable and disable the facility as needed. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 53 +

[Intel-gfx] [RFC 11/14] drm/i915: Engine busy time tracking

From: Tvrtko Ursulin Track total time requests have been executing on the hardware. To make this cheap it is hidden behind a static branch with the intention that it is only enabled when there is a consumer listening. This means that in the default off case the total

[Intel-gfx] [RFC 13/14] drm/i915: Export engine busy stats in debugfs

From: Tvrtko Ursulin Export the stats added in the previous patch in debugfs. Number of active clients reading this data is tracked and the static key is only enabled whilst there are some. Userspace is intended to keep the file descriptor open, seeking to the

[Intel-gfx] [RFC 05/14] drm/i915/pmu: Helper to extract engine and sampler from PMU config

From: Tvrtko Ursulin Less hardcoded shifts and ands in the code is better. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pmu.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git

[Intel-gfx] [RFC 00/14] i915 PMU and engine busy stats

From: Tvrtko Ursulin Rough sketch of the idea I mentioned a few times to various people - merging the engine busyness tracking with Chris i915 PMU RFC. First patch is the actual PMU RFC by Chris. It is followed by some cleanup patches, then come a few improvements,

[Intel-gfx] [RFC 02/14] drm/i915/pmu: Add VCS2 engine to the PMU uAPI

From: Tvrtko Ursulin It is missing from the original patch. Signed-off-by: Tvrtko Ursulin --- include/uapi/drm/i915_drm.h | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/include/uapi/drm/i915_drm.h

[Intel-gfx] [RFC 01/14] RFC drm/i915: Expose a PMU interface for perf queries

From: Chris Wilson The first goal is to be able to measure GPU (and invidual ring) busyness without having to poll registers from userspace. (Which not only incurs holding the forcewake lock indefinitely, perturbing the system, but also runs the risk of hanging the

[Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result

This adds the connector name when printing a debug message about the DP link training result. It is useful to figure out what connector is failing when multiple DP connectors are used. Signed-off-by: Paul Kocialkowski ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drain the device workqueue on unload (rev2)

== Series Details == Series: drm/i915: Drain the device workqueue on unload (rev2) URL : https://patchwork.freedesktop.org/series/26494/ State : success == Summary == Series 26494v2 drm/i915: Drain the device workqueue on unload

[Intel-gfx] [PATCH v2] drm/i915: Drain the device workqueue on unload

Workers on the i915->wq may rearm themselves so for completeness we need to replace our flush_workqueue() with a call to drain_workqueue() before unloading the device. v2: Reinforce the drain_workqueue with an preceeding rcu_barrier() as a few of the tasks that need to be drained may first be

[Intel-gfx] ✓ Fi.CI.BAT: success for Fixed16.16 wrapper cleanup & wm optimization (rev6)

== Series Details == Series: Fixed16.16 wrapper cleanup & wm optimization (rev6) URL : https://patchwork.freedesktop.org/series/25692/ State : success == Summary == Series 25692v6 Fixed16.16 wrapper cleanup & wm optimization

[Intel-gfx] [PATCH 7/8] drm/i915/bxt+: Enable IPC support

From: "Kumar, Mahesh" This patch adds IPC support. This patch also enables IPC in all supported platforms based on has_ipc flag. IPC (Isochronous Priority Control) is the hardware feature, which dynamically controls the memory read priority of Display. When IPC is

[Intel-gfx] [PATCH 8/8] drm/i915/skl+: debugfs entry to control IPC

From: "Kumar, Mahesh" This patch creates an entry in debugfs to check the status of IPC. This can also be used to enable/disable IPC in supported platforms. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_debugfs.c | 73

[Intel-gfx] [PATCH 4/8] drm/i915/glk: IPC linetime watermark workaround for GLK

From: "Kumar, Mahesh" IF IPC is enabled LINETIME_WM value should be half of calculated value line time = ROUNDDOWN(1/2 * Calculated Line Time) Earlier code was rounding-up the value, But updated Bspec says we should take the ROUNDDOWN. This patch corrects that as well.

[Intel-gfx] [PATCH 5/8] drm/i915/cnl: Extend WM workaround with IPC for CNL

From: "Kumar, Mahesh" CNL:A & CNL:B have same workaround as KBL to increase wm level latency by 4us if IPC is enabled. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[Intel-gfx] [PATCH 6/8] drm/i915/gen9+: Add has_ipc flag in device info structure

From: "Kumar, Mahesh" New Isochronous Priority Control (IPC) capability is introduced in newer GEN platforms. This patch adds a device info flag to indicate if platform supports IPC. Patch also sets this flag in supported platforms. Signed-off-by: Mahesh Kumar

[Intel-gfx] [PATCH 2/8] drm/i915/skl+: Optimize WM calculation

From: "Kumar, Mahesh" Plane configuration parameters doesn't change for each WM-level calculation. Currently we compute same parameters 8 times for each wm-level. This patch optimizes it by calculating these parameters in beginning & reuse during each level-wm

[Intel-gfx] [PATCH 3/8] drm/i915/gen10: Calculate and enable transition WM

From: "Kumar, Mahesh" GEN > 9 require transition WM to be programmed if IPC is enabled. This patch calculates & enable transition WM for supported platforms. If transition WM is enabled, Plane read requests are sent at high priority until filling above the transition

[Intel-gfx] [PATCH 1/8] drm/i915: Fixed point fixed16 wrapper cleanup

From: "Kumar, Mahesh" As per suggestion from Jani, cleanup the code. Cleanup includes - Instead of left shifting & check, compare with U32/16_MAX - Use typecast instead of clamp_t Signed-off-by: Mahesh Kumar Cc: Jani Nikula

[Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization

This series Include patches for: clean fixed16.16 wrappers optimize wm calculation code enable/Implement trans wm calculation create a DebugFS entry for IPC status Mahesh Kumar (8): drm/i915: Fixed point fixed16 wrapper cleanup drm/i915/skl+: Optimize WM

Re: [Intel-gfx] [PATCH v3 0/2] Handle unsupported configuration with IF-ID

Hi Daniel, On Monday 17 July 2017 12:56 PM, Daniel Vetter wrote: On Fri, Jun 30, 2017 at 05:40:58PM +0530, Mahesh Kumar wrote: Gen9+ Interlace fetch mode doesn't support few plane configurations & pipe scaling. - Y-tile - 90/270 rotation - pipe/plane scaling - 420 planar formats Do

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for net/sch_generic: Shut up noise

On Tue, Jul 18, 2017 at 11:14:35AM -, Patchwork wrote: > == Series Details == > > Series: net/sch_generic: Shut up noise > URL : https://patchwork.freedesktop.org/series/27475/ > State : success > > == Summary == > > Series 27475v1 net/sch_generic: Shut up noise >

  1   2   >