[Intel-gfx] [PATCH] drm/i915: Fix botched merge that downgrades CSR versions.

Merge commit 5e580523d9128a4d8 reverts the version bumping parts of commit 4aa7fb9c3c4fa0. Bump the versions again and request the specific firmware version. The currently recommended versions are: SKL 1.26, KBL 1.01 and BXT 1.07. Cc: Patrik Jakobsson Cc: Imre Deak Bugzilla: https://bugs.freede

Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

On Mon, 15 Aug 2016, Eric Engestrom wrote: > On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote: >> On Mon, 15 Aug 2016, Eric Engestrom wrote: >> > Signed-off-by: Eric Engestrom >> > --- >> > >> > I moved the main bits to be the first diffs, shouldn't affect anything >> > when applying

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

Hi Dave - Intel fixes, either terribly late or terribly early this week. ;) BR, Jani. The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel ta

Re: [Intel-gfx] [PATCH] drm/i915: Fix botched merge that downgrades CSR versions.

On ma, 2016-08-15 at 15:09 +0200, Maarten Lankhorst wrote: > Merge commit 5e580523d9128a4d8 reverts the version bumping parts of > commit 4aa7fb9c3c4fa0. Bump the versions again and request the specific > firmware version. > > The currently recommended versions are: SKL 1.26, KBL 1.01 and BXT 1.07

Re: [Intel-gfx] [PATCH RFC 0/4] svm support

On Mon, Aug 15, 2016 at 02:48:03PM +0300, Mika Kuoppala wrote: > Hi, > > Now when fences got merged I reworked the series. It is now much > smaller in size. Some items are still missing like error state recording, > fault handling, documentation and in fences. What's the plan for KMS integration?

Re: [Intel-gfx] [PATCH] drm/i915: Fix botched merge that downgrades CSR versions.

Op 15-08-16 om 15:27 schreef Imre Deak: > On ma, 2016-08-15 at 15:09 +0200, Maarten Lankhorst wrote: >> Merge commit 5e580523d9128a4d8 reverts the version bumping parts of >> commit 4aa7fb9c3c4fa0. Bump the versions again and request the specific >> firmware version. >> >> The currently recommended

Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

On Mon, Aug 15, 2016 at 04:13:54PM +0300, Jani Nikula wrote: > On Mon, 15 Aug 2016, Eric Engestrom wrote: > > On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote: > >> On Mon, 15 Aug 2016, Eric Engestrom wrote: > >> > Signed-off-by: Eric Engestrom > >> > --- > >> > > >> > I moved the mai

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

On 27 July 2016 at 11:23, Daniel Vetter wrote: > On Fri, Jul 22, 2016 at 03:21:29PM +0100, Emil Velikov wrote: >> On 15 July 2016 at 16:42, Marius Vlad wrote: >> >> >> Side note: this will conflict with Robert Foss's work to make >> >> libdrm_intel an optional dependency. Have you/others had the

Re: [Intel-gfx] [PATCH] drm/i915: Fix botched merge that downgrades CSR versions.

On ma, 2016-08-15 at 15:46 +0200, Maarten Lankhorst wrote: > Op 15-08-16 om 15:27 schreef Imre Deak: > > On ma, 2016-08-15 at 15:09 +0200, Maarten Lankhorst wrote: > > > Merge commit 5e580523d9128a4d8 reverts the version bumping parts > > > of > > > commit 4aa7fb9c3c4fa0. Bump the versions again an

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix botched merge that downgrades CSR versions.

== Series Details == Series: drm/i915: Fix botched merge that downgrades CSR versions. URL : https://patchwork.freedesktop.org/series/11108/ State : failure == Summary == Series 11108v1 drm/i915: Fix botched merge that downgrades CSR versions. http://patchwork.freedesktop.org/api/1.0/series/11

[Intel-gfx] [PATCH] drm/i915: Use common RPS scheme for Cherryview

Cherryview uses a custom static definition of its RPS parameters (for automatically driving GPU frequency selection) - yet still couples into the waitboosting scheme of the common RPS setup. The rationale given in commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail") was that Cherry

Re: [Intel-gfx] [PATCH 1/9] drm/i915/cmdparser: Make initialisation failure non-fatal

On Mon, Aug 15, 2016 at 12:56:44PM +0100, Matthew Auld wrote: > On 12 August 2016 at 16:07, Chris Wilson wrote: > > If the developer adds a register in the wrong order, we BUG during boot. > > That makes development and testing very difficult. Let's be a bit more > > friendly and disable the comma

[Intel-gfx] [PATCH 04/18] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set

From: Akash Goel So far PM IER/IIR/IMR registers were being used only for Turbo related interrupts. But interrupts coming from GuC also use the same set. As a precursor to supporting GuC interrupts, added new low level routines so as to allow sharing the programming of PM IER/IIR/IMR registers be

[Intel-gfx] [PATCH 07/18] relay: Use per CPU constructs for the relay channel buffer pointers

From: Akash Goel relay essentially needs to maintain the per CPU array of channel buffer pointers but it manually creates that array. Instead its better to avail the per CPU constructs, provided by the kernel, to allocate & access the array of pointer to channel buffers. v2: Include in relay.h

[Intel-gfx] [PATCH 03/18] drm/i915: New structure to contain GuC logging related fields

From: Akash Goel So far there were 2 fields related to GuC logs in 'intel_guc' structure. For the support of capturing GuC logs & storing them in a local buffer, multiple new fields would have to be added. This warrants a separate structure to contain the fields related to GuC logging state. Adde

[Intel-gfx] [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset

From: Sagar Arun Kamble Before capturing the GuC logs as a part of error state, there should be a force log buffer flush action sent to GuC before proceeding with GPU reset and re-initializing GUC. There could be some data in the log buffer which is yet to be captured and those logs would be part

[Intel-gfx] [PATCH 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer

From: Akash Goel Added the dump of GuC log buffer to i915 error state, as the contents of GuC log buffer would also be useful to determine that why the GPU reset was triggered. v2: - For uniformity use existing helper function print_error_obj() to dump out contents of GuC log buffer, pretty pr

[Intel-gfx] [PATCH 17/18] drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer

From: Akash Goel In order to have fast reads from the GuC log buffer, used SSE4.1 movntdqa based memcpy function i915_memcpy_from_wc. GuC log buffer has a WC type vmalloc mapping and copying using movntqda from WC type memory is almost as fast as reading from WB memory. This will further reduce t

[Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

From: Sagar Arun Kamble GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state structure, once it has consumed the log buffer contents by copying them to a file or buffer. Even if Host couldn't copy the c

[Intel-gfx] [PATCH v6 00/18] Support for sustained capturing of GuC firmware logs

From: Akash Goel GuC firmware log its debug messages into a Host-GuC shared memory buffer and when the buffer is half full it sends a Flush interrupt to Host. GuC firmware follows the half-full draining protocol where it expects that while it is writing to 2nd half of the buffer, first half would

[Intel-gfx] [PATCH 01/18] drm/i915: Decouple GuC log setup from verbosity parameter

From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level module param i915.guc_log_level. User would be given a provision to enable firmware logging at runtime, through a host2guc action, and not necessarily during Driver load time. But the address of log buffer can be p

[Intel-gfx] [PATCH 12/18] drm/i915: Increase GuC log buffer size to reduce flush interrupts

From: Akash Goel In cases where GuC generate logs at a very high rate, correspondingly the rate of flush interrupts is also very high. So far total 8 pages were allocated for storing both ISR & DPC logs. As per the half-full draining protocol followed by GuC, by doubling the number of pages, the

[Intel-gfx] [PATCH 09/18] drm/i915: New lock to serialize the Host2GuC actions

From: Akash Goel With the addition of new Host2GuC actions related to GuC logging, there is a need of a lock to serialize them, as they can execute concurrently with each other and also with other existing actions. v2: Use mutex in place of spinlock to serialize, as sleep can happen while wa

[Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface, where Driver will have to just use a relay API to store snapshots of the GuC log buffer in the buffer managed by relay. The

[Intel-gfx] [PATCH 05/18] drm/i915: Support for GuC interrupts

From: Sagar Arun Kamble There are certain types of interrupts which Host can receive from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel. This patch adds support to receive interrupts from GuC but currently enables &

[Intel-gfx] [PATCH 16/18] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer

From: Akash Goel Host needs to sample the GuC log buffer on every flush interrupt from GuC. To ensure that we always get the up-to-date data from log buffer, its better to access the buffer through an uncached CPU mapping. Also the way buffer is accessed from GuC & Host side, manually doing cache

[Intel-gfx] [PATCH 10/18] drm/i915: Add stats for GuC log buffer flush interrupts

From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full. GuC firmware also tracks how many times the buffer overflowed. It would be useful to maintain a statistics of how many flush interrupts were received and for which type of log buffer, along with th

[Intel-gfx] [PATCH 15/18] drm/i915: Debugfs support for GuC logging control

From: Sagar Arun Kamble This patch provides debugfs interface i915_guc_output_control for on the fly enabling/disabling of logging in GuC firmware and controlling the verbosity level of logs. The value written to the file, should have bit 0 set to enable logging and bits 4-7 should contain the ve

[Intel-gfx] [PATCH 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer

From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full, so Driver doesn't really need to sample the complete buffer and can just copy only the newly written data by GuC into the local buffer, i.e. as per the read & write pointer values. Moreover the flu

[Intel-gfx] [PATCH 02/18] drm/i915: Add GuC ukernel logging related fields to fw interface file

From: Sagar Arun Kamble The first page of the GuC log buffer contains state info or meta data which is required to parse the logs contained in the subsequent pages. The structure representing the state info is added to interface file as Driver would need to handle log buffer flush interrupts from

Re: [Intel-gfx] [PATCH 6/9] drm/i915/cmdparser: Compare against the previous command descriptor

On Mon, Aug 15, 2016 at 12:00:32PM +0100, Matthew Auld wrote: > On 12 August 2016 at 16:07, Chris Wilson wrote: > > On the blitter (and in test code), we see long sequences of repeated > > commands, e.g. XY_PIXEL_BLT, XY_SCANLINE_BLT, or XY_SRC_COPY. For these, > > we can skip the hashtable lookup

[Intel-gfx] [PATCH 18/18] drm/i915: Early creation of relay channel for capturing boot time logs

From: Akash Goel As per the current i915 Driver load sequence, debugfs registration is done at the end and so the relay channel debugfs file is also created after that but the GuC firmware is loaded much earlier in the sequence. As a result Driver could miss capturing the boot-time logs of GuC fi

[Intel-gfx] [PATCH v3 09/11] drm/i915: add oa_event_min_timer_exponent sysctl

The minimal sampling period is now configurable via a dev.i915.oa_min_timer_exponent sysctl parameter. Following the precedent set by perf, the default is the minimum that won't (on its own) exceed the default kernel.perf_event_max_sample_rate default of 10 samples/s. Signed-off-by: Robert Br

[Intel-gfx] [PATCH v3 03/11] drm/i915: return EACCES for check_cmd() failures

check_cmd() is checking whether a command adheres to certain restrictions that ensure it's safe to execute within a privileged batch buffer. Returning false implies a privilege problem, not that the command is invalid. The distinction makes the difference between allowing the buffer to be executed

[Intel-gfx] [PATCH v3 07/11] drm/i915: advertise available metrics via sysfs

Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics//id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via DRM_IOCTL_I915_PERF_OPEN.

[Intel-gfx] [PATCH v3 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before adding more gen7 OA registers Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h| 2 +- 2 files chang

[Intel-gfx] [PATCH v3 00/11] Enable Gen 7 Observation Architecture

Mostly just a rebase on a more recent nightly, except for an update to how POLLIN events are reported to reduce the CPU overhead that was otherwise seen while running gputop. The problem seen with poll was largely a fault with gputop having multiple redundant 200ms, but out-of-phase, timers tracke

[Intel-gfx] [PATCH v3 01/11] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl()

[Intel-gfx] [PATCH v3 10/11] drm/i915: Add more Haswell OA metric sets

This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. The code is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml > scripts/i915-pe

[Intel-gfx] [PATCH v3 04/11] drm/i915: don't whitelist oacontrol in cmd parser

Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL vi

[Intel-gfx] [PATCH v3 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

In particular this tries to capture for posterity some of the early challenges we had with using the core perf infrastructure in case we ever want to revisit adapting perf for device metrics. Cc: Chris Wilson Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_perf.c | 163 +++

[Intel-gfx] [PATCH v3 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. Cc: Chris Wilson Signed-off-by: Robert Bragg Signed-off-by: Zhenyu

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Use common RPS scheme for Cherryview

== Series Details == Series: drm/i915: Use common RPS scheme for Cherryview URL : https://patchwork.freedesktop.org/series/0/ State : failure == Summary == Series 0v1 drm/i915: Use common RPS scheme for Cherryview http://patchwork.freedesktop.org/api/1.0/series/0/revisions/1/mbox

[Intel-gfx] [PATCH v3 08/11] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_dr

[Intel-gfx] [PATCH v3 05/11] drm/i915: Add 'render basic' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml > scripts/i915-perf-kernelgen.py $ make -C gpu

[Intel-gfx] Current drm-intel-next status on broadwell platform

Hello, I tested drm-intel-next published Aug 9th 2016. I'm facing two major bugs: 1) hard lockups with fbc enabled (neverending story it seems to be) 2) screen tearing in browsers and video players (I do not use any kind of compositor) Should I fire a bug report? both of these two were OK in dr

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Support for GuC interrupts

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Sagar Arun Kamble There are certain types of interrupts which Host can receive from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel. This patch adds support to r

Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Add i915 perf infrastructure

On Mon, Aug 15, 2016 at 03:41:18PM +0100, Robert Bragg wrote: > Adds base i915 perf infrastructure for Gen performance metrics. > > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 > properties to configure a stream of metrics and returns a new fd usable > with standard VFS

Re: [Intel-gfx] [PATCH v3 03/11] drm/i915: return EACCES for check_cmd() failures

On Mon, Aug 15, 2016 at 03:41:20PM +0100, Robert Bragg wrote: > check_cmd() is checking whether a command adheres to certain > restrictions that ensure it's safe to execute within a privileged batch > buffer. Returning false implies a privilege problem, not that the > command is invalid. > > The d

Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

On Mon, Aug 15, 2016 at 03:52:07PM +0200, Daniel Vetter wrote: > On Mon, Aug 15, 2016 at 04:13:54PM +0300, Jani Nikula wrote: > > On Mon, 15 Aug 2016, Eric Engestrom wrote: > > > On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote: > > >> On Mon, 15 Aug 2016, Eric Engestrom wrote: > > >>

Re: [Intel-gfx] [PATCH 02/10] drm/i915/userptr: Make gup errors stickier

Chris Wilson writes: > Keep any error reported by the gup_worker until we are notified that the > arena has changed (via the mmu-notifier). This has the importance of > making two consecutive calls to i915_gem_object_get_pages() reporting > the same error, and curtailing an loop of detecting a fa

[Intel-gfx] ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev7)

== Series Details == Series: Support for sustained capturing of GuC firmware logs (rev7) URL : https://patchwork.freedesktop.org/series/7910/ State : failure == Summary == Series 7910v7 Support for sustained capturing of GuC firmware logs http://patchwork.freedesktop.org/api/1.0/series/7910/re

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable Gen 7 Observation Architecture (rev5)

== Series Details == Series: Enable Gen 7 Observation Architecture (rev5) URL : https://patchwork.freedesktop.org/series/3024/ State : failure == Summary == Applying: drm/i915: Add i915 perf infrastructure Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/Makefile M

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state structure, once it has consumed the log buffer contents by copying them to

Re: [Intel-gfx] linux-firmware-i915 pull request (restore skl dmc 1.23)

On Thu, Aug 11, 2016 at 06:22:56PM +, Vivi, Rodrigo wrote: > The following changes since commit > c170c8d95794d6aedbaeea44674daaa96baf04f7: > >   linux-firmware: intel: Update Skylake audio firmware (2016-08-04 > 16:09:21 +0530) > > are available in the git repository at: > >   git://people.

Re: [Intel-gfx] [PATCH 02/10] drm/i915/userptr: Make gup errors stickier

On Mon, Aug 15, 2016 at 06:08:21PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > + if (obj->userptr.work) { > > /* active flag should still be held for the pending work */ > > - return -EAGAIN; > > + if (IS_ERR(obj->userptr.work)) > > +

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface, where Driver will have to just use a relay API to store snapshots of the

[Intel-gfx] [FIXUP] drm: remove `const` attribute to hint at caller that they now own the memory

Signed-off-by: Eric Engestrom --- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- drivers/gpu/drm/drm_atomic.c| 2 +- drivers/gpu/drm/drm_crtc.c

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full, so Driver doesn't really need to sample the complete buffer and can just copy only the newly written data by GuC into the local buffer, i.e. as per

[Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

Rendering operations to the dma-buf are tracked implicitly via the reservation_object (dmabuf->resv). This is used to allow poll() to wait upon outstanding rendering (or just query the current status of rendering). The dma-buf sync ioctl allows userspace to prepare the dma-buf for CPU access, which

[Intel-gfx] [PATCH v2] drm/i915: Use common RPS scheme for Cherryview

Cherryview uses a custom static definition of its RPS parameters (for automatically driving GPU frequency selection) - yet still couples into the waitboosting scheme of the common RPS setup. The rationale given in commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail") was that Cherry

Re: [Intel-gfx] [PATCH 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel Added the dump of GuC log buffer to i915 error state, as the contents of GuC log buffer would also be useful to determine that why the GPU reset was triggered. v2: - For uniformity use existing helper function print_error_obj() t

Re: [Intel-gfx] [PATCH v2] drm/i915: Use common RPS scheme for Cherryview

Apolgies, I changed trees between resending after the first git-send-email bounced off the wrong address. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.or

[Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

Rendering operations to the dma-buf are tracked implicitly via the reservation_object (dmabuf->resv). This is used to allow poll() to wait upon outstanding rendering (or just query the current status of rendering). The dma-buf sync ioctl allows userspace to prepare the dma-buf for CPU access, which

Re: [Intel-gfx] [PATCH v3 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Mon, Aug 15, 2016 at 03:41:23PM +0100, Robert Bragg wrote: > int __must_check i915_gem_evict_something(struct drm_device *dev, > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c > b/drivers/gpu/drm/i915/i915_gem_context.c > index bd13d08..b4de357 100644 > --- a/drivers/gpu/drm/i915/i915_ge

Re: [Intel-gfx] [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Sagar Arun Kamble Before capturing the GuC logs as a part of error state, there should be a force log buffer flush action sent to GuC before proceeding with GPU reset and re-initializing GUC. There could be some data in the log buffer which

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

On 8/15/2016 8:50 PM, Tvrtko Ursulin wrote: On 15/08/16 15:49, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state structure, once it has cons

Re: [Intel-gfx] [PATCH 18/18] drm/i915: Early creation of relay channel for capturing boot time logs

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel As per the current i915 Driver load sequence, debugfs registration is done at the end and so the relay channel debugfs file is also created after that but the GuC firmware is loaded much earlier in the sequence. As a result Driver

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: make drm_get_format_name thread-safe (rev2)

== Series Details == Series: drm: make drm_get_format_name thread-safe (rev2) URL : https://patchwork.freedesktop.org/series/11069/ State : failure == Summary == Applying: drm: remove `const` attribute to hint at caller that they now own the memory fatal: sha1 information is lacking or useles

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On 8/15/2016 8:59 PM, Tvrtko Ursulin wrote: On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface, where Driver will have to

Re: [Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote: > Rendering operations to the dma-buf are tracked implicitly via the > reservation_object (dmabuf->resv). This is used to allow poll() to > wait upon outstanding rendering (or just query the current status of > rendering). The dma-buf sy

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Debugfs support for GuC logging control

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Sagar Arun Kamble This patch provides debugfs interface i915_guc_output_control for on the fly enabling/disabling of logging in GuC firmware and controlling the verbosity level of logs. The value written to the file, should have bit 0 set to

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote: > +static void guc_read_update_log_buffer(struct intel_guc *guc) > +{ > + struct guc_log_buffer_state *log_buffer_state, > *log_buffer_snapshot_state; > + struct guc_log_buffer_state log_buffer_state_local; > + void

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: > +void i915_guc_register(struct drm_i915_private *dev_priv) > +{ > + if (!i915.enable_guc_submission) > + return; The final state of i915.enable_guc_submission is not known at this time. Does it matter if you se

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer

On 8/15/2016 9:06 PM, Tvrtko Ursulin wrote: On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full, so Driver doesn't really need to sample the complete buffer and can just copy only the newly written

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote: > On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: > > +void i915_guc_register(struct drm_i915_private *dev_priv) > > +{ > > + if (!i915.enable_guc_submission) > > + return; > > The final state of i915.e

[Intel-gfx] ✗ Ro.CI.BAT: failure for dma-buf: Wait on the reservation object when sync'ing before CPU access

== Series Details == Series: dma-buf: Wait on the reservation object when sync'ing before CPU access URL : https://patchwork.freedesktop.org/series/6/ State : failure == Summary == Series 6v1 dma-buf: Wait on the reservation object when sync'ing before CPU access http://patchwork.free

Re: [Intel-gfx] [PATCH RFC 1/4] drm/i915: add create_context2 ioctl

On Mon, Aug 15, 2016 at 09:25:15AM -0700, Jesse Barnes wrote: > On Mon, 2016-08-15 at 13:56 +0100, Chris Wilson wrote: > > On Mon, Aug 15, 2016 at 03:25:43PM +0300, Mika Kuoppala wrote: > > > > > > Chris Wilson writes: > > > > > > > > > > > On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppal

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On 8/15/2016 9:42 PM, Chris Wilson wrote: On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote: On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: +void i915_guc_register(struct drm_i915_private *dev_priv) +{ + if (!i915.enable_guc_submission) +

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On Mon, Aug 15, 2016 at 10:08:15PM +0530, Goel, Akash wrote: > > > On 8/15/2016 9:42 PM, Chris Wilson wrote: > >On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote: > >>On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: > >>>+void i915_guc_register(struct drm_i915_priv

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

On 8/15/2016 9:36 PM, Chris Wilson wrote: On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote: +static void guc_read_update_log_buffer(struct intel_guc *guc) +{ + struct guc_log_buffer_state *log_buffer_state, *log_buffer_snapshot_state; + struct guc_log_buffer_st

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

On Mon, Aug 15, 2016 at 10:16:56PM +0530, Goel, Akash wrote: > > > On 8/15/2016 9:36 PM, Chris Wilson wrote: > >On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote: > >>+static void guc_read_update_log_buffer(struct intel_guc *guc) > >>+{ > >>+ struct guc_log_buffer_state *log_

[Intel-gfx] [PATCH] drm/i915: Silence GCC warning for cmn_a_well

Just make the logic simple enough for even GCC to understand (and foolproof against random changes): drivers/gpu/drm/i915/intel_runtime_pm.c: warning: 'cmn_a_well' may be used uninitialized in this function [-Wuninitialized]: => 871:23 Reported-by: Geert Uytterhoeven Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v3 05/21] drm/i915: Get rid of HAS_CORE_RING_FREQ

On Tue, Aug 09, 2016 at 07:59:38PM +0100, Chris Wilson wrote: > On Tue, Aug 09, 2016 at 11:45:11AM -0700, Carlos Santa wrote: > > No need for HAS_CORE_RING_FREQ as that flag is actually the same as > > .has_llc. Feedback from V. Syrjala. > > > > Signed-off-by: Carlos Santa > > --- > > drivers/gp

Re: [Intel-gfx] [PATCH v3 02/21] drm/i915: Remove .is_mobile field from platform struct

On Tue, Aug 09, 2016 at 11:45:08AM -0700, Carlos Santa wrote: > As recommended by Ville Syrjala removing .is_mobile field from the > platform struct definition for vlv and hsw+ GPUs as there's no need to > make the distinction in later hardware anymore. Keep it for older GPUs > as it is still neede

Re: [Intel-gfx] [PATCH v3 04/21] drm/i915: Move HAS_RUNTIME_PM definition to platform

On Tue, Aug 09, 2016 at 11:45:10AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > > Feedb

Re: [Intel-gfx] [PATCH v3 06/21] drm/i915 Move HAS_CSR definition to platform definition

On Tue, Aug 09, 2016 at 11:45:12AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > > Signe

Re: [Intel-gfx] [PATCH v3 07/21] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

On Tue, Aug 09, 2016 at 11:45:13AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > > Signe

Re: [Intel-gfx] [PATCH v3 08/21] drm/i915: Move HAS_RC6 definition to platform definition

On Tue, Aug 09, 2016 at 11:45:14AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > > Signe

Re: [Intel-gfx] [PATCH v3 09/21] drm/i915: Move HAS_RC6p definition to platform definition

On Tue, Aug 09, 2016 at 11:45:15AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > > Signe

Re: [Intel-gfx] [PATCH v3 10/21] drm/i915: Move HAS_DP_MST definition to platform definition

On Tue, Aug 09, 2016 at 11:45:16AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > > Signe

Re: [Intel-gfx] [PATCH v3 11/21] drm/i915: Introduce GEN5_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:17AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben w. Maybe this comment and also on the previous GEN6_FEATURE could be improved. And also good to Cc people you are mentioning on the commit message. Besides I still believe we should add thi

Re: [Intel-gfx] [PATCH v3 12/21] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

On Tue, Aug 09, 2016 at 11:45:18AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > Revie

Re: [Intel-gfx] [PATCH v3 13/21] drm/i915: Introduce GEN4_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:19AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. same comments as for gen5 > > Use it for i965g, i965gm, g45 and gm45. > > Signed-off-by: Carlos Santa Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_pci.c | 36 +

Re: [Intel-gfx] [PATCH v3 14/21] drm/i915: Introduce GEN3_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:20AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES from Ben W. > same as previous > Use it for i915g, i915gm, i945g, i945gm, g33 and pnv. > > Signed-off-by: Carlos Santa Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_pci.c | 30 +

Re: [Intel-gfx] [PATCH v3 15/21] drm/i915: Introduce GEN2_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:21AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > same as others > Use it for 830, 845g, i85x, i865g. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_pci.c | 37 - > 1 file ch

Re: [Intel-gfx] [PATCH v3 16/21] drm/i915: Move HAS_HW_CONTEXTS definition to platform

On Tue, Aug 09, 2016 at 11:45:22AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > > Signed-off-b

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

Em Sáb, 2016-08-13 às 10:05 +0100, Chris Wilson escreveu: > On Fri, Aug 12, 2016 at 11:24:59PM +, Pandiyan, Dhinakaran wrote: > Do we know why we get black screens in this scenario? I don't know exactly, but I can speculate that it's probably because the display engine fails to decompress the

Re: [Intel-gfx] [PATCH v3 17/21] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform

On Tue, Aug 09, 2016 at 11:45:23AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > Reviewed-by:

Re: [Intel-gfx] [PATCH v3 18/21] drm/i915: Move HAS_L3_DPF definition to platform definition

On Tue, Aug 09, 2016 at 11:45:24AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > Reviewed-by:

<    1   2   3   >