Re: [Intel-gfx] [PATCH] drm/i915: Flush everything on switching to the kernel_context

Quoting Joonas Lahtinen (2017-11-27 11:18:55) > On Sun, 2017-11-26 at 21:48 +, Chris Wilson wrote: > > Even though all rendering should have been flushed at the end of the > > previous requests, add an extra flush after switching to the > > kernel_context. As the switch to the kernel_context

Re: [Intel-gfx] linux-4.15-rc1/drivers/gpu/drm/i915/gvt/cmd_parser.c:1640: poor error checking ?

Thanks for the email. It has been refined recently, the code can be found here: https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/i915/gvt/cmd_parser.c Thanks for the notification, again. :) -Original Message- From: David Binderman [mailto:dcb...@hotmail.com] Sent: Monday,

[Intel-gfx] [PATCH igt] igt/gem_ctx_isolation: Check isolation of registers between contexts

A new context assumes that all of its registers are in the default state when it is created. What may happen is that a register written by one context may leak into the second, causing mass confusion. v2: Extend back to Sandybridge (etc) v3: Check context preserves registers across

Re: [Intel-gfx] [PATCH i-g-t v5 0/6] kms_ccs improvements

Gabriel Krisman Bertazi writes: > Hi, > > This is a new version of the series with the updates requested by > reviewers. It fixes the KBL issue pointed out by Arkadiusz, adds a test > for pitches[1] mentioned by Ville and does some other improvements. > > It does not

[Intel-gfx] [PATCH 2/2] drm/i915: hide unused intel_panel_set_backlight function

Building i915 without backlight support results in a harmless warning for intel_panel_set_backlight: drivers/gpu/drm/i915/intel_panel.c:653:13: error: 'intel_panel_set_backlight' defined but not used [-Werror=unused-function] This moves it into the CONFIG_BACKLIGHT_CLASS_DEVICE section that its

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v4] drm/i915: Expose the busyspin durations for i915_wait_request (rev2)

== Series Details == Series: series starting with [v4] drm/i915: Expose the busyspin durations for i915_wait_request (rev2) URL : https://patchwork.freedesktop.org/series/34404/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup

Re: [Intel-gfx] [PATCH i-g-t 1/2] igt: Remove Android support

On 24.11.2017 17:17, Arkadiusz Hiler wrote: This patch gets rid of the Android support, deleting all the hacks and moving code around to the places it belongs. Android build is not really maintained properly and rots rather fast. With recent push for Meson here and Android going for Soong it

Re: [Intel-gfx] [PATCH] drm/i915: Disable THP until we have a GPU read BW W/A

> -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Monday, November 27, 2017 11:13 AM > To: Intel graphics driver community testing & development g...@lists.freedesktop.org> > Cc: Joonas Lahtinen ; Auld, Matthew >

Re: [Intel-gfx] [PATCH] drm/i915: Record default HW state in the GPU error state

Quoting Joonas Lahtinen (2017-11-27 12:02:03) > On Sun, 2017-11-26 at 22:09 +, Chris Wilson wrote: > > It may be of interest to both compare the active HW context against the > > default (or NULL) context, to see what has been changed and if either are > > corrupt. > > > > Signed-off-by:

[Intel-gfx] [PATCH] drm/i915: Rename i915_gem_timelines_mark_idle

The kerneldoc markup for i915_gem_timelines_mark_idle() was incorrect, so take the opportunity to also convert it from the "mark_idle" to "park" naming scheme. drivers/gpu/drm/i915/i915_gem_timeline.c:120: warning: No description found for parameter 'i915' Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Record default HW state in the GPU error state

On Sun, 2017-11-26 at 22:09 +, Chris Wilson wrote: > It may be of interest to both compare the active HW context against the > default (or NULL) context, to see what has been changed and if either are > corrupt. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala

Re: [Intel-gfx] [PATCH] drm/i915: Rename i915_gem_timelines_mark_idle

On Mon, 2017-11-27 at 12:30 +, Chris Wilson wrote: > The kerneldoc markup for i915_gem_timelines_mark_idle() was incorrect, > so take the opportunity to also convert it from the "mark_idle" to "park" > naming scheme. > > drivers/gpu/drm/i915/i915_gem_timeline.c:120: warning: No description

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/gem_ctx_isolation: Check isolation of registers between contexts (rev8)

== Series Details == Series: igt/gem_ctx_isolation: Check isolation of registers between contexts (rev8) URL : https://patchwork.freedesktop.org/series/32531/ State : success == Summary == Test kms_flip: Subgroup vblank-vs-dpms-suspend: notrun -> INCOMPLETE

[Intel-gfx] [QUERY] How many CI mails is too many?

Hey all, For some time already CI sends out 1-2 mails per series per (re)run, i.e. BAT results and "full IGT" results (if BAT has not failed). Recently we have added 32bit build check, and if that fails it sends out additional mail In-Reply-To the series. I am working on adding some static

[Intel-gfx] [PATCH 1/2] drm/i915: fix intel_backlight_device_register declaration

The alternative intel_backlight_device_register() definition apparently never got used, but I have now run into a case of i915 being compiled without CONFIG_BACKLIGHT_CLASS_DEVICE, resulting in a number of identical warnings: drivers/gpu/drm/i915/intel_drv.h:1739:12: error:

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_ctx_isolation: Check isolation of registers between contexts (rev8)

== Series Details == Series: igt/gem_ctx_isolation: Check isolation of registers between contexts (rev8) URL : https://patchwork.freedesktop.org/series/32531/ State : success == Summary == IGT patchset tested on top of latest successful build 4c57ff468fa4870184b3da56432602f967af

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Update shrinker drm_i915_private naming convention

On Thu, 2017-11-23 at 11:53 +, Chris Wilson wrote: > Switch over from the non-descript dev_priv locals to i915. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen It's very much its own island of code anyway. Reviewed-by:

Re: [Intel-gfx] [PATCH igt] igt/perf_pmu: Keep batch_duration_ns as the minimum measurement duration

On 27/11/2017 11:02, Chris Wilson wrote: We have chosen batch_duration_ns to be the minimum duration we need to meet our accuracy requirements for legacy ringbuffer PMU sampling. As such, we need to be careful to use multiples of it during tests, and not split it into different phases with a

[Intel-gfx] [PATCH V3 08/29] drm/gma500: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Add domain parameter

[Intel-gfx] [PATCH V3 13/29] powerpc/powermac: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-code the domain

[Intel-gfx] [PATCH V3 06/29] edd: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Domain number is not

[Intel-gfx] [PATCH V3 05/29] agp: nvidia: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Replace

[Intel-gfx] [PATCH V3 07/29] ibft: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). We don't search for

[Intel-gfx] [PATCH V3 00/29] PCI: deprecate pci_get_bus_and_slot()

Deprecate pci_get_bus_and_slot() in favor of pci_get_domain_bus_and_slot() in order to remove domain 0 assumptions in the kernel. pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain

[Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Extract the domain

[Intel-gfx] [PATCH V3 01/29] alpha/PCI: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't extract the domain number. Other places, use

[Intel-gfx] [PATCH V3 03/29] x86/PCI: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use domain number of 0

[Intel-gfx] [PATCH V3 04/29] ata: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rename i915_gem_timelines_mark_idle

== Series Details == Series: drm/i915: Rename i915_gem_timelines_mark_idle URL : https://patchwork.freedesktop.org/series/34457/ State : failure == Summary == Series 34457 revision 1 was fully merged or fully failed: no git log ___ Intel-gfx

[Intel-gfx] [PATCH V3 14/29] bnx2x: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Introduce

[Intel-gfx] [PATCH V3 15/29] pch_gbe: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use the domain

[Intel-gfx] [PATCH V3 18/29] PCI/quirks: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Extract the domain

[Intel-gfx] [PATCH V3 19/29] PCI/syscall: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-coding the domain

[Intel-gfx] [PATCH V3 20/29] xen: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't extract the domain number. Other places, use

[Intel-gfx] [PATCH V3 21/29] openprom: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-coding the domain

[Intel-gfx] [PATCH V3 02/29] powerpc/PCI: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use

[Intel-gfx] [PATCH V3 17/29] PCI: ibmphp: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-coding the domain

[Intel-gfx] [PATCH V3 16/29] PCI: cpqhp: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-coding the domain

[Intel-gfx] [PATCH V3 11/29] Drivers: ide: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Replace

[Intel-gfx] [PATCH V3 12/29] iommu/amd: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-code the domain

[Intel-gfx] [PATCH V3 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Replace

[Intel-gfx] [PATCH V3 23/29] staging: rts5208: remove rtsx_read_pci_cfg_byte()

Remove unused rtsx_read_pci_cfg_byte() function. Signed-off-by: Sinan Kaya --- drivers/staging/rts5208/rtsx.c | 17 - drivers/staging/rts5208/rtsx.h | 2 -- 2 files changed, 19 deletions(-) diff --git a/drivers/staging/rts5208/rtsx.c

[Intel-gfx] [PATCH V3 22/29] [media] atomisp: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function. Since ISP always uses domain 0, hard-code it in the code when

[Intel-gfx] [PATCH V3 24/29] backlight: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-coding the domain

Re: [Intel-gfx] [QUERY] How many CI mails is too many?

I feel we generally tend to ignore the results mails for series that we are not actively involved on (although we might be interested in series itself). Also if number of revisions some series can undergo is high, this tendency can grow. How about the option of sending the results mails to

[Intel-gfx] [PATCH V3 27/29] video: fbdev: riva: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). struct riva_par has a

[Intel-gfx] [PATCH V3 28/29] i7300_idle: remove unused file

i7300_idle.h is not being called by any source file and contains calls to pci_get_bus_and_slot() that we are trying to deprecate. Remove unused file. Signed-off-by: Sinan Kaya --- include/linux/i7300_idle.h | 84 -- 1 file

[Intel-gfx] [PATCH V3 29/29] PCI: remove pci_get_bus_and_slot() function

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Now that all users of pci_get_bus_and_slot() switched to pci_get_domain_bus_and_slot(), it is now safe to remove this

[Intel-gfx] [PATCH V3 26/29] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). struct nvidia_par has

[Intel-gfx] [PATCH V3 25/29] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Find the domain number

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: fix intel_backlight_device_register declaration

== Series Details == Series: series starting with [1/2] drm/i915: fix intel_backlight_device_register declaration URL : https://patchwork.freedesktop.org/series/34467/ State : failure == Summary == Series 34467 revision 1 was fully merged or fully failed: no git log

[Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters

We currently have two module parameters that control GuC: "enable_guc_loading" and "enable_guc_submission". Whenever we need submission=1, we also need loading=1.We also need loading=1 when we want to want to verify the HuC, which is every time we have a HuC (but all platforms with HuC have a GuC

[Intel-gfx] [PATCH 0/2] drm/i915/guc : Removing GuC loading and submission modparams

The aim of this series is to remove the enable_guc_loading and enable_guc_submission module parameters. They are being replaced by a common, newly defined enable_guc module parameter. This series has been split from a bigger series that has previously been sent to this mailing list. Cc: Daniele

[Intel-gfx] [PATCH v10 2/2] drm/i915/guc : Updating GuC and HuC firmware select function

Updating GuC and HuC firmware select function to support removing i915_modparams.enable_guc_loading module parameter. v2: Clarifying the commit message (Anusha) v3: Unify seq_puts messages, Re-factoring code as per review (Michal) v4: Rebase v5: Separating message unification into a separate

Re: [Intel-gfx] [PATCH v3] drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too

On Mon, Nov 27, 2017 at 08:16:15AM +, Valtteri Rantala wrote: > Testing the texture read performance shows that the same tuning for > the SQ credits is needed on GLK as on BXT/APL. This has been also > confirmed by Altug from the HW team. > > V3: Rebase + fix > Signed-off-by: Valtteri Rantala

Re: [Intel-gfx] [PATCH V3 08/29] drm/gma500: deprecate pci_get_bus_and_slot()

+dri-de...@lists.freedesktop.org On 11/27/2017 11:57 AM, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove

Re: [Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

+dri-de...@lists.freedesktop.org On 11/27/2017 11:57 AM, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove

Re: [Intel-gfx] [PATCH V3 04/29] ata: deprecate pci_get_bus_and_slot()

On Mon, Nov 27, 2017 at 11:57:41AM -0500, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove pci_get_bus_and_slot()

Re: [Intel-gfx] [QUERY] How many CI mails is too many?

On Mon, Nov 27, 2017 at 02:54:02PM +, Arkadiusz Hiler wrote: > Hey all, > > For some time already CI sends out 1-2 mails per series per (re)run, i.e. BAT > results and "full IGT" results (if BAT has not failed). > > Recently we have added 32bit build check, and if that fails it sends out >

[Intel-gfx] linux-firmware pull request(SKL:DMC)

Hi Ben, Kyle, Please consider pulling i915 updates to linux-firmware.git. i915-firmware-2017-11-27 The following changes since commit 17e6288135d4500f9fe60224dce2b46d850c346b: brcm: update firmware for bcm4358 (2017-11-25 10:15:53 -0500) are available in the git repository at:

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WA Display #1178 to fix some type C dongles

On Thu, Nov 23, 2017 at 7:21 AM, Ville Syrjälä wrote: > On Wed, Nov 22, 2017 at 10:55:14AM -0800, Lucas De Marchi wrote: >> WA Display #1178 is meant to fix Aux channel voltage swing too low with >> some type C dongles. Although it is for type C, HW engineers

[Intel-gfx] [PATCH igt] igt: Remove gem_ctx_basic

This is just a very plain stress test that doesn't do any verification, and is entirely duplicated by the other context tests. The test currently leaks objects from every thread on every pass, while fixing it would be trivial, it also is pointless as the test is of little merit. Signed-off-by:

[Intel-gfx] [PATCH igt] igt/perf_pmu: Keep batch_duration_ns as the minimum measurement duration

We have chosen batch_duration_ns to be the minimum duration we need to meet our accuracy requirements for legacy ringbuffer PMU sampling. As such, we need to be careful to use multiples of it during tests, and not split it into different phases with a test, like multi_client does. Signed-off-by:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Enable hotplug polling after registering the outputs

== Series Details == Series: drm/i915: Enable hotplug polling after registering the outputs URL : https://patchwork.freedesktop.org/series/34445/ State : success == Summary == Test kms_flip: Subgroup flip-vs-expired-vblank-interruptible: fail -> PASS

Re: [Intel-gfx] [PATCH] drm/i915: Flush everything on switching to the kernel_context

On Sun, 2017-11-26 at 21:48 +, Chris Wilson wrote: > Even though all rendering should have been flushed at the end of the > previous requests, add an extra flush after switching to the > kernel_context. As the switch to the kernel_context is used when idling > the gpu (e.g. suspend), having an

[Intel-gfx] ✗ Fi.CI.BAT: warning for igt/perf_pmu: Keep batch_duration_ns as the minimum measurement duration

== Series Details == Series: igt/perf_pmu: Keep batch_duration_ns as the minimum measurement duration URL : https://patchwork.freedesktop.org/series/34450/ State : warning == Summary == IGT patchset tested on top of latest successful build 4c57ff468fa4870184b3da56432602f967af intel/pmu:

[Intel-gfx] [PATCH i-g-t] meson: gtkdoc support

Bunch of neat improvements: - xml generates correctly depend upon the test binaries - no need to re-run autogen.sh when new chapters/functions get added, all handed by meson Still one issue: - the gtkdoc target doesn't depend upon the custom_target yet, hacked around using build_by_default:

Re: [Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

On Sat, 2017-11-25 at 00:48 +0100, Thomas Gleixner wrote: > On Fri, 24 Nov 2017, Matthew Auld wrote: > > > From: Joonas Lahtinen > > Please CC the linux kernel mailinglist on patches related to x86. The > MAINTAINERS file says: > > X86 ARCHITECTURE (32-BIT AND

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] lib: avoid < in gtkdoc comments (rev3)

== Series Details == Series: series starting with [1/4] lib: avoid < in gtkdoc comments (rev3) URL : https://patchwork.freedesktop.org/series/34413/ State : success == Summary == IGT patchset tested on top of latest successful build 4c57ff468fa4870184b3da56432602f967af intel/pmu: Catch-up

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too (rev3)

== Series Details == Series: drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too (rev3) URL : https://patchwork.freedesktop.org/series/33772/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

Re: [Intel-gfx] [PATCH i-g-t 3/4] lib: move write_stderr out of the #ifdef

On 26/11/2017 19:42, Daniel Vetter wrote: Helps with making it compile everywhere. This fixes: commit db31e3c1ca0953b6e6832c25060acd01012a66dd Author: Tvrtko Ursulin Date: Wed Nov 8 12:06:52 2017 + lib/core: Avoid unused result in backtrace printing

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rename shrinker init/cleanup to match driver initialisation phase

On Thu, 2017-11-23 at 11:53 +, Chris Wilson wrote: > Since the shrinker is registered and unregistered during > i915_driver_register and i915_driver_unregister, respectively, rename > the init/cleanup functions to match. > > Signed-off-by: Chris Wilson > Cc: Joonas

[Intel-gfx] [PATCH v3] drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too

Testing the texture read performance shows that the same tuning for the SQ credits is needed on GLK as on BXT/APL. This has been also confirmed by Altug from the HW team. V3: Rebase + fix Signed-off-by: Valtteri Rantala --- drivers/gpu/drm/i915/intel_engine_cs.c | 15

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/4] lib: avoid < in gtkdoc comments (rev3)

== Series Details == Series: series starting with [1/4] lib: avoid < in gtkdoc comments (rev3) URL : https://patchwork.freedesktop.org/series/34413/ State : warning == Summary == Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (shard-snb)

Re: [Intel-gfx] [PATCH V3 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()

+nouv...@lists.freedesktop.org On 11/27/2017 11:57 AM, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc : Removing GuC loading and submission modparams

== Series Details == Series: drm/i915/guc : Removing GuC loading and submission modparams URL : https://patchwork.freedesktop.org/series/34490/ State : failure == Summary == Applying: drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters Patch failed at 0001

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too (rev3)

On Mon, Nov 27, 2017 at 08:20:26AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too > (rev3) > URL : https://patchwork.freedesktop.org/series/33772/ > State : failure > > == Summary == > > CHK

Re: [Intel-gfx] [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Wednesday, November 22, 2017 11:15 PM >To: Srivatsa, Anusha ; intel- >g...@lists.freedesktop.org >Cc: Srivatsa, Anusha ; Ville Syrjala

[Intel-gfx] [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

Forward Error Correction is supported on DP 1.4. This patch adds corresponding DPCD register definitions. v2: Add dri-devel to the CC list Cc: dri-de...@lists.freedesktop.org Cc: Ville Syrjala Cc: Jani Nikula Cc: Manasi Navare

[Intel-gfx] linux-4.15-rc1/drivers/gpu/drm/i915/gvt/cmd_parser.c:1640: poor error checking ?

Hello there, linux-4.15-rc1/drivers/gpu/drm/i915/gvt/cmd_parser.c:1640]: (style) Checking if unsigned variable 'bb_size' is less than zero. Source code is /* get the size of the batch buffer */ bb_size = find_bb_size(s); if (bb_size < 0) return -EINVAL; but static int

Re: [Intel-gfx] [PATCH 13/15] drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangle

This looks okay to me. Reviewed-by: Sinclair Yeh On Thu, Nov 23, 2017 at 09:05:00PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > Note that this replaces

[Intel-gfx] [PATCH] drm/i915: Mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 141432 Addresses-Coverity-ID: 141433 Addresses-Coverity-ID: 141434 Addresses-Coverity-ID: 141435 Addresses-Coverity-ID: 141436 Addresses-Coverity-ID: 1357360

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt: Remove gem_ctx_basic

== Series Details == Series: igt: Remove gem_ctx_basic URL : https://patchwork.freedesktop.org/series/34500/ State : failure == Summary == Series 34500 revision 1 was fully merged or fully failed: no git log ___ Intel-gfx mailing list

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Avoid enum conversion warning (rev2)

On Sun, 2017-11-26 at 20:40 -0800, Nick Desaulniers wrote: > Do I need to be basing my patches on a different tree than Linus'? In > general, how do people find what tree they should be basing their > patch off of? "T:" line from the MAINTAINERS entry would tell you that. Regards, Joonas --

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4] drm/i915: Expose the busyspin durations for i915_wait_request (rev2)

== Series Details == Series: series starting with [v4] drm/i915: Expose the busyspin durations for i915_wait_request (rev2) URL : https://patchwork.freedesktop.org/series/34404/ State : success == Summary == Series 34404v2 series starting with [v4] drm/i915: Expose the busyspin durations

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Disable THP until we have a GPU read BW W/A

== Series Details == Series: drm/i915: Disable THP until we have a GPU read BW W/A URL : https://patchwork.freedesktop.org/series/34441/ State : warning == Summary == Test kms_flip: Subgroup flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw)

Re: [Intel-gfx] [PATCH] drm/i915: Enable hotplug polling after registering the outputs

Quoting Maarten Lankhorst (2017-11-27 10:18:46) > Op 27-11-17 om 10:45 schreef Chris Wilson: > > Previously we would enable hotplug polling on the outputs immediately > > upon construction. This would allow a very early hotplug event to > > trigger before we had finishing setting up the driver to

Re: [Intel-gfx] [PATCH i-g-t] i-g-t: kms_plane_scaling: Enhanced scaling tests

> -Original Message- > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Monday, November 27, 2017 2:47 PM > To: Srinivas, Vidya > Cc: intel-gfx > Subject: Re: [Intel-gfx] [PATCH

[Intel-gfx] [PATCH] drm/i915: Disable THP until we have a GPU read BW W/A

We seem to be missing some W/A for 2M pages and are getting a hit on raw GPU read bandwidths (even 30%) even though the GPU write bandwidths improve (even 10%). For now, disable THP, which is our only practical source of 2M pages until we have a W/A for the issue. v2: - Be explicit that we talk

Re: [Intel-gfx] [PATCH i-g-t] i-g-t: kms_plane_scaling: Enhanced scaling tests

Somehow I forgot to send out my irc feedback to the m-l. On Wed, Nov 22, 2017 at 9:15 AM, Vidya Srinivas wrote: > +igt_main > { > data_t data = {}; > > @@ -308,11 +765,26 @@ igt_simple_main > data.drm_fd = drm_open_driver(DRIVER_INTEL); >

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Expose the busyspin durations for i915_wait_request

Quoting Sagar Arun Kamble (2017-11-27 07:20:01) > > > On 11/26/2017 5:50 PM, Chris Wilson wrote: > > An interesting discussion regarding "hybrid interrupt polling" for NVMe > > came to the conclusion that the ideal busyspin before sleeping > > I think hybrid approach suggests sleep (1/2

Re: [Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

On Fri, 2017-11-24 at 22:05 +, Chris Wilson wrote: > Quoting Matthew Auld (2017-11-24 21:29:22) > > From: Joonas Lahtinen > > > > In preparation for upcoming SKUs, allow more freedom in placement > > of the Intel graphics stolen memory by BIOS to full 64bit

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable THP until we have a GPU read BW W/A

== Series Details == Series: drm/i915: Disable THP until we have a GPU read BW W/A URL : https://patchwork.freedesktop.org/series/34441/ State : success == Summary == Series 34441v1 drm/i915: Disable THP until we have a GPU read BW W/A

[Intel-gfx] [PATCH] drm/i915: Enable hotplug polling after registering the outputs

Previously we would enable hotplug polling on the outputs immediately upon construction. This would allow a very early hotplug event to trigger before we had finishing setting up the driver to handle it. Instead, move the output polling to the last step of registration, after we have set up all

[Intel-gfx] [PATCH v4] drm/i915: Expose the busyspin durations for i915_wait_request

An interesting discussion regarding "hybrid interrupt polling" for NVMe came to the conclusion that the ideal busyspin before sleeping was half of the expected request latency (and better if it was already halfway through that request). This suggested that we too should look again at our tradeoff

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable hotplug polling after registering the outputs

== Series Details == Series: drm/i915: Enable hotplug polling after registering the outputs URL : https://patchwork.freedesktop.org/series/34445/ State : success == Summary == Series 34445v1 drm/i915: Enable hotplug polling after registering the outputs

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags

On Fri, 2017-11-24 at 11:21 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Will be adding a new per-engine flags shortly so it makes sense > to consolidate. > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Enable hotplug polling after registering the outputs

Op 27-11-17 om 10:45 schreef Chris Wilson: > Previously we would enable hotplug polling on the outputs immediately > upon construction. This would allow a very early hotplug event to > trigger before we had finishing setting up the driver to handle it. > Instead, move the output polling to the

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid enum conversion warning

On Sun, Nov 26, 2017 at 07:49:14PM -0800, Nick Desaulniers wrote: > Fixes the following enum conversion warning: > > drivers/gpu/drm/i915/intel_ddi.c:1481:30: error: implicit conversion > from enumeration type 'enum port' to different enumeration type 'enum > intel_dpll_id'

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Avoid enum conversion warning (rev2)

On Mon, Nov 27, 2017 at 2:26 AM, Joonas Lahtinen wrote: > On Sun, 2017-11-26 at 20:40 -0800, Nick Desaulniers wrote: >> In >> general, how do people find what tree they should be basing their >> patch off of? > > "T:" line from the MAINTAINERS entry would tell you

  1   2   >