[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence (rev2)

== Series Details == Series: series starting with [v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence (rev2) URL : https://patchwork.freedesktop.org/series/11266/ State : warning == Summary == Series 11266v2 Series without cover letter

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Sync against the GuC log buffer flush work item on system suspend

On to, 2016-08-18 at 19:17 +0530, Goel, Akash wrote: > [...] > Thanks for the inputs. Sorry not familiar with freezable WQ semantics. > But after looking at code, this is what I understood :- > 1. freezable Workqueues will be frozen before the system suspend > callbacks are invoked for the

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Drop ORIGIN_GTT for untracked GTT writes (rev2)

== Series Details == Series: drm/i915: Drop ORIGIN_GTT for untracked GTT writes (rev2) URL : https://patchwork.freedesktop.org/series/11255/ State : failure == Summary == Applying: drm/i915: Drop ORIGIN_GTT for untracked GTT writes fatal: sha1 information is lacking or useless

Re: [Intel-gfx] [PATCH v2 0/4] Picture aspect ratio support in DRM layer

Hi, On 09-08-2016 15:55, Shashank Sharma wrote: > This patch series adds 4 patches. > - The first two patches add aspect ratio support in DRM layes > - Next two patches add new aspect ratios defined in CEA-861-F > supported for HDMI 2.0 4k modes. > > Adding aspect ratio support in DRM layer: >

Re: [Intel-gfx] [PATCH v2] drm/i915: Drop ORIGIN_GTT for untracked GTT writes

On to, 2016-08-18 at 15:26 +0100, Chris Wilson wrote: > If FBC is set on a framebuffer that is unmapped, all GTT faults will be > from a partial mapping. Writes by the user through the partial VMA are > then untracked by the FBC and so we must use the ORIGIN_CPU when flushing > the

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf

Chris Wilson writes: > If userspace is asynchronously streaming into the batch or other > execobjects, we may not flush those writes along with a change in cache > domain (as there is no change). Therefore those writes may end up in > internal chipset buffers and not

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf

On Thu, Aug 18, 2016 at 04:59:35PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > If userspace is asynchronously streaming into the batch or other > > execobjects, we may not flush those writes along with a change in cache > > domain (as there is no change).

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Sync against the GuC log buffer flush work item on system suspend

On 8/18/2016 7:48 PM, Imre Deak wrote: On to, 2016-08-18 at 19:17 +0530, Goel, Akash wrote: [...] Thanks for the inputs. Sorry not familiar with freezable WQ semantics. But after looking at code, this is what I understood :- 1. freezable Workqueues will be frozen before the system suspend

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Convert intel_dp to use atomic state

On Tue, Aug 09, 2016 at 05:04:13PM +0200, Maarten Lankhorst wrote: > Slightly less straightforward. Some of the drrs calls are done from > workers or from intel_ddi.c, pass along crtc_state when we can, > or crtc->config when we can't. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 00/15] drm/i915: Use connector atomic state in encoders.

On Tue, Aug 09, 2016 at 05:03:59PM +0200, Maarten Lankhorst wrote: > This is required for supporting nonblocking modeset and atomic connector > properties. > Connector properties will need the connector state to be passed or it will > not work > as intended. > > Nonblocking modesets need to

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Sync against the GuC log buffer flush work item on system suspend

On to, 2016-08-18 at 20:05 +0530, Goel, Akash wrote: > > On 8/18/2016 7:48 PM, Imre Deak wrote: > > On to, 2016-08-18 at 19:17 +0530, Goel, Akash wrote: > > > [...] > > > Thanks for the inputs. Sorry not familiar with freezable WQ semantics. > > > But after looking at code, this is what I

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Use more atomic state in intel_color.c

On Tue, Aug 09, 2016 at 05:04:14PM +0200, Maarten Lankhorst wrote: > crtc_state is already passed around, use it instead of crtc->config. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

On Thu, Aug 18, 2016 at 01:56:56PM +, Zanoni, Paulo R wrote: > Em Qui, 2016-08-18 às 09:21 +0100, Chris Wilson escreveu: > > Only fbc1 is tied to using a fence. Later iterations of fbc are more > > flexible and allow operation on unfenced frontbuffers. > > But then we'll lose GTT tracking -

Re: [Intel-gfx] [PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote: > Hey, > > Op 17-08-16 om 21:55 schreef Lyude: > > > > Since the watermark calculations for Skylake are still broken, we're apt > > to hitting underruns very easily under multi-monitor configurations. > > While it would be lovely if

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

On to, 2016-08-18 at 09:21 +0100, Chris Wilson wrote: > Only fbc1 is tied to using a fence. Later iterations of fbc are more > flexible and allow operation on unfenced frontbuffers. > > Signed-off-by: Chris Wilson > Cc: Daniel Vetter > Cc:

[Intel-gfx] [PATCH v2] drm/i915: Drop ORIGIN_GTT for untracked GTT writes

If FBC is set on a framebuffer that is unmapped, all GTT faults will be from a partial mapping. Writes by the user through the partial VMA are then untracked by the FBC and so we must use the ORIGIN_CPU when flushing the I915_GEM_DOMAIN_GTT. v2: Keep ORIGIN_CPU for set-to-domain(.write=CPU)

[Intel-gfx] [PATCH v4 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

[Intel-gfx] [PATCH v4 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

[Intel-gfx] [PATCH v4 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

[Intel-gfx] [PATCH v4 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 >

[Intel-gfx] [PATCH v4 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 ---

[Intel-gfx] [PATCH v4 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 ---

[Intel-gfx] [PATCH v4 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

[Intel-gfx] [PATCH v4 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

[Intel-gfx] [PATCH] drm/i915/dp/mst: Validate modes against the available link bandwidth

Change intel_dp_mst_mode_valid() to use available link bandwidth rather than the link's maximum supported bandwidth to evaluate whether modes are legal for the current configuration. This takes into account the fact that link bandwidth may already be dedicated to other virtual channels.

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

Hi Jonathan, Today's linux-next merge of the jc_docs tree got a conflict in: Documentation/gpu/index.rst between commit: b754b35b089d ("vgaarbiter: rst-ifiy and polish kerneldoc") from the drm-misc tree and commit: 505f711174b0 ("doc-rst: add index to sub-folders") from the jc_docs

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

On Mon, Aug 15, 2016 at 4:04 PM, Chris Wilson wrote: > 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.

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Add function to return port from an encoder

On Mon, Aug 15, 2016 at 05:00:53PM -0700, Dhinakaran Pandiyan wrote: > There are places in the driver where we just need the 'port' associated > with an encoder and not 'struct intel_digital_port' that contains it. > This basically is a generic implementation of intel_ddi_get_encoder_port() >

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit

== Series Details == Series: Enable i915 perf stream for Haswell OA unit URL : https://patchwork.freedesktop.org/series/11295/ 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

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm: Allow drivers to modify plane_state in prepare_fb/cleanup_fb

== Series Details == Series: series starting with [1/2] drm: Allow drivers to modify plane_state in prepare_fb/cleanup_fb URL : https://patchwork.freedesktop.org/series/11285/ State : failure == Summary == Series 11285v1 Series without cover letter

[Intel-gfx] ✗ Ro.CI.BAT: failure for Reclassify messages from GuC loader/submission (rev4)

== Series Details == Series: Reclassify messages from GuC loader/submission (rev4) URL : https://patchwork.freedesktop.org/series/10918/ State : failure == Summary == Applying: drm: extra printk() wrapper macros Using index info to reconstruct a base tree... M include/drm/drmP.h Falling

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: use symbolic names for module parameter values (rev3)

== Series Details == Series: drm/i915/guc: use symbolic names for module parameter values (rev3) URL : https://patchwork.freedesktop.org/series/10188/ State : failure == Summary == Series 10188v3 drm/i915/guc: use symbolic names for module parameter values

[Intel-gfx] [PATCH v4 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

[Intel-gfx] [PATCH v4 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

[Intel-gfx] [PATCH v4 00/11] Enable i915 perf stream for Haswell OA unit

I've updated the stream->ops->read() interface to avoid the struct i915_perf_read_state so it's hopefully a bit clearer to see the state being passed around: int (*read)(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t

[Intel-gfx] [PATCH v4 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 v4 1/4] drm: extra printk() wrapper macros

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and once-only macros for each of the levels INFO, NOTICE, and WARNING, using a common

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_guc_submission.c | 18

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

Various downgrading, upgrading, or general reorganisation of the messages emitted by the GuC code. As general principles: * "can't happen" cases (inconsistencies/misconfiguration) are ERRORs * recoverable (ignored) errors are downgraded to WARNINGs * important auxiliary messages about failure or

[Intel-gfx] [PATCH v4 1/5] drm/i915/guc: symbolic names for GuC submission preferences

The existing code that accesses the "enable_guc_submission" parameter uses explicit numerical values for the various possibilities, including in one case relying on boolean 0/1 mapping to specific values (which could be confusing for maintainers). So this patch just provides and uses names for

[Intel-gfx] [PATCH v4 0/5] drm/i915/guc: use symbolic names for module parameter values

There are various literal constants used in the GuC module-parameter processing code; this sequence of patches replaces them with symbolic names for greater clarity. And then it re-enables GuC submission by default v3: Original patch broken into two (1/4 + 2/4) Name for GuC log level NONE

[Intel-gfx] [PATCH v4 2/5] drm/i915/guc: symbolic names for GuC firmare loading preferences

The existing code that accesses the "enable_guc_loading" parameter uses explicit numerical values for the various possibilities, including in one case relying on boolean 0/1 mapping to specific values (which could be confusing for maintainers). So this patch just provides and uses names for the

[Intel-gfx] [PATCH v4 4/5] drm/i915/guc: use symbolic names in setting defaults for module parameters

Of course, this also re-enables GuC loading and submission by default on suitable platforms, since it's Intel's Plan of Record that GuC submission shall be used where available. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c | 10 +- 1 file

[Intel-gfx] [PATCH v4 5/5] drm/i915/guc: ignore unrecognised loading & submission options

Previously the code allowed *any* values for the enable_guc_loading and enable_guc_submission parameters, and forced them into range by clipping at each extremum. This version instead ignores unknown values, treating them as DEFAULT (which then gets converted to DISABLED or PREFERRED). Of course

[Intel-gfx] [PATCH v4 3/5] drm/i915/guc: symbolic name for GuC log-level none

The existing code that accesses the "guc_log_level" parameter uses an explicit numerical value for the "no logging" case, whereas there are symbolic names for the other levels. So this patch just provides and uses a name for the default log level (NONE), with the same numeric value that is

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(), a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(), and one eliminated completely. v2: different permutation of levels :) v3: convert a couple of "this shouldn't happen" messages to WARN() Signed-off-by: Dave Gordon

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

Update GuC firmware version to 8.11, and re-enable GuC loading and submission by default on suitable platforms, since it's Intel's Plan of Record that GuC submission shall be used where available. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c |

[Intel-gfx] [PATCH 2/2] drm/i915: Replace intel_plane->wait_req with plane->fence

Now that we subclass our request from struct fence, we start using the common primitives more freely and so avoid hand-rolling routines already provided for by the helpers. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_atomic_plane.c | 3 --

[Intel-gfx] [PATCH 1/2] drm: Allow drivers to modify plane_state in prepare_fb/cleanup_fb

The drivers have to modify the atomic plane state during the prepare_fb callback so they track allocations, reservations and dependencies for this atomic operation involving this fb. In particular, how else do we set the plane->fence from the framebuffer! Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip (rev2)

== Series Details == Series: drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip (rev2) URL : https://patchwork.freedesktop.org/series/11142/ State : warning == Summary == Series 11142v2 drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip

[Intel-gfx] [PATCH] drm/i915: vfree() no longer ignores the low bits of the address

Since vfree() now likes to WARN when passed a none page-aligned pointer, we need to discard the low bits to comply with it. Fixes: d31d7cb1460c ("drm/i915: Support for creating write combined type vmaps") Signed-off-by: Chris Wilson Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Hey, Op 17-08-16 om 21:55 schreef Lyude: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from this

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/9] drm: Extract drm_encoder.[hc]

== Series Details == Series: series starting with [1/9] drm: Extract drm_encoder.[hc] URL : https://patchwork.freedesktop.org/series/11235/ State : failure == Summary == Series 11235v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/11235/revisions/1/mbox Test

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Drop ORIGIN_GTT for untracked GTT writes

== Series Details == Series: drm/i915: Drop ORIGIN_GTT for untracked GTT writes URL : https://patchwork.freedesktop.org/series/11255/ State : failure == Summary == Applying: drm/i915: Drop ORIGIN_GTT for untracked GTT writes fatal: sha1 information is lacking or useless

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915/fbc: Don't set an illegal fence if unfenced

== Series Details == Series: series starting with [1/2] drm/i915/fbc: Don't set an illegal fence if unfenced URL : https://patchwork.freedesktop.org/series/11256/ State : failure == Summary == Series 11256v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fallback to single page pwrite/pread if unable to release fence

On ke, 2016-08-17 at 18:33 +0100, Chris Wilson wrote: > If we cannot release the fence (for example if someone is inexplicably > trying to write into a tiled framebuffer that is currently pinned to the > display! *cough* kms_frontbuffer_tracking *cough*) fallback to using the > page-by-page

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Check live status before reading edid"

On Wed, Aug 17, 2016 at 04:43:36PM +0300, Jani Nikula wrote: > On Wed, 17 Aug 2016, Chris Wilson wrote: > > On Wed, Aug 17, 2016 at 03:47:48PM +0300, David Weinehall wrote: > >> This reverts commit 237ed86c693d8a8e4db476976aeb30df4deac74b. > >> > >> Our current

[Intel-gfx] [PATCH v3 2/2] drm/i915/get_params: Add HuC status to getparams

This patch will allow for getparams to return the status of the HuC. As the HuC has to be validated by the GuC this patch uses the validated status to show when the HuC is loaded and ready for use. You cannot use the loaded status as with the GuC as the HuC is verified after it is loaded and is

[Intel-gfx] [PATCH v3 1/2] drm/i915/get_params: Add GuC status to getparams

This patch returns the GuC status to the caller. It is used so that the userspace knows if the GuC has been loaded. Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_drv.c | 4 drivers/gpu/drm/i915/intel_guc.h| 2 +-

[Intel-gfx] [PATCH v3 0/2] HuC/GuC status to Get Params.

As it states on the tin. Add the HuC/GuC patches to the Get params so that they can be accessed from userspace. This is a requirement for the opensourcing of media codecs that require the HuC/GuC. These patches require the HuC enabling patches. patchset: HuC Loading Patches. v2: removed extra

[Intel-gfx] ✗ Ro.CI.BAT: failure for HuC/GuC status to Get Params. (rev3)

== Series Details == Series: HuC/GuC status to Get Params. (rev3) URL : https://patchwork.freedesktop.org/series/11158/ State : failure == Summary == Applying: drm/i915/get_params: Add GuC status to getparams Using index info to reconstruct a base tree... M

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Organize most GPU features by platform (rev4)

== Series Details == Series: drm/i915: Organize most GPU features by platform (rev4) URL : https://patchwork.freedesktop.org/series/10102/ State : failure == Summary == Series 10102v4 drm/i915: Organize most GPU features by platform

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,01/35] drm/i915: Use ORIGIN_CPU for fb invalidation from pwrite

== Series Details == Series: series starting with [CI,01/35] drm/i915: Use ORIGIN_CPU for fb invalidation from pwrite URL : https://patchwork.freedesktop.org/series/11251/ State : failure == Summary == Series 11251v1 Series without cover letter

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: fix some audio support 4K resolution issues

== Series Details == Series: drm/i915: fix some audio support 4K resolution issues URL : https://patchwork.freedesktop.org/series/11252/ State : failure == Summary == Series 11252v1 drm/i915: fix some audio support 4K resolution issues

[Intel-gfx] [PATCH v4 1/3] drm/i915: set proper N/M in modeset

From: Libin Yang When modeset occurs and the LS_CLK is set to some special values in DP mode, the N/M need to be set manually if audio is playing. Otherwise the first several seconds may be silent in audio playback. The relationship of Maud and Naud is expressed in

[Intel-gfx] [PATCH v4 2/3] drm/i915: set proper N/MCTS on more platforms

From: Libin Yang This patch applies setting proper N/M, N/CTS on more platforms. Signed-off-by: Libin Yang --- drivers/gpu/drm/i915/intel_audio.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git

[Intel-gfx] [PATCH v4 3/3] drm/i915: HDMI audio gets the TMDS clock by crtc_clock

From: Libin Yang HDMI audio should use crtc_clock to get the TMDS clock. This patch renames mode to adjusted_mode to unify the name. Signed-off-by: Libin Yang --- drivers/gpu/drm/i915/intel_audio.c | 14 +++--- 1 file changed, 7

[Intel-gfx] [PATCH v4 0/3] drm/i915: fix some audio support 4K resolution issues

From: Libin Yang changelog: v1: initial patches v2: change to use crtc->config->port_clock instead of mode->clock for dp change to use mode->crtc_clock instead of mode->clock rename mode to adjusted_mode v3: add support for 270MHz add more platforms

[Intel-gfx] ✗ Ro.CI.BAT: failure for Finally fix watermarks (rev10)

== Series Details == Series: Finally fix watermarks (rev10) URL : https://patchwork.freedesktop.org/series/10276/ State : failure == Summary == Series 10276v10 Finally fix watermarks http://patchwork.freedesktop.org/api/1.0/series/10276/revisions/10/mbox Test drv_module_reload_basic:

[Intel-gfx] [PATCH] drm/i915: Drop ORIGIN_GTT for untracked GTT writes

If FBC is set on a framebuffer that is unmapped, all GTT faults will be from a partial mapping. Writes by the user through the partial VMA are then untracked by the FBC and so we must use the ORIGIN_CPU when flushing the I915_GEM_DOMAIN_GTT. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 1/2] drm/i915/fbc: Don't set an illegal fence if unfenced

If the frontbuffer doesn't have an associated fence, it will have a fence reg of -1. If we attempt to OR in this register into the FBC control register we end up setting all control bits, oops! Signed-off-by: Chris Wilson Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

Only fbc1 is tied to using a fence. Later iterations of fbc are more flexible and allow operation on unfenced frontbuffers. Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: "Zanoni, Paulo R" ---

Re: [Intel-gfx] [PATCH 2/2] drm/i915: add module param for live_status

On Wed, Aug 17, 2016 at 10:35:31AM +0100, Chris Wilson wrote: > On Wed, Aug 17, 2016 at 12:25:40PM +0300, David Weinehall wrote: > > On Wed, Aug 17, 2016 at 09:08:58AM +0100, Chris Wilson wrote: > > > On Wed, Aug 17, 2016 at 11:02:32AM +0300, David Weinehall wrote: > > > > Since the workaround for

Re: [Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

On 4 August 2016 at 17:09, Daniel Vetter wrote: > On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote: >> On 4 August 2016 at 14:15, Sharma, Shashank >> wrote: >> > On 8/4/2016 5:04 PM, Emil Velikov wrote: >> >> >> >> On 4 August 2016 at

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Sync against the GuC log buffer flush work item on system suspend

On to, 2016-08-18 at 09:15 +0530, Goel, Akash wrote: > > On 8/17/2016 9:07 PM, Goel, Akash wrote: > > > > > > On 8/17/2016 6:41 PM, Imre Deak wrote: > > > On ke, 2016-08-17 at 18:15 +0530, Goel, Akash wrote: > > > > > > > > On 8/17/2016 5:11 PM, Chris Wilson wrote: > > > > > On Wed, Aug 17,

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: vfree() no longer ignores the low bits of the address

== Series Details == Series: drm/i915: vfree() no longer ignores the low bits of the address URL : https://patchwork.freedesktop.org/series/11260/ State : failure == Summary == Series 11260v1 drm/i915: vfree() no longer ignores the low bits of the address

Re: [Intel-gfx] [PATCH] drm/i915: vfree() no longer ignores the low bits of the address

On 18/08/16 10:01, Chris Wilson wrote: Since vfree() now likes to WARN when passed a none page-aligned pointer, we need to discard the low bits to comply with it. Fixes: d31d7cb1460c ("drm/i915: Support for creating write combined type vmaps") Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbc: Don't set an illegal fence if unfenced

On to, 2016-08-18 at 09:21 +0100, Chris Wilson wrote: > @@ -190,9 +190,11 @@ static void g4x_fbc_activate(struct drm_i915_private > *dev_priv) >   dpfc_ctl |= DPFC_CTL_LIMIT_2X; >   else >   dpfc_ctl |= DPFC_CTL_LIMIT_1X; > - dpfc_ctl |= DPFC_CTL_FENCE_EN |

Re: [Intel-gfx] [PATCH] drm/i915: vfree() no longer ignores the low bits of the address

On to, 2016-08-18 at 10:01 +0100, Chris Wilson wrote: > Since vfree() now likes to WARN when passed a none page-aligned pointer, > we need to discard the low bits to comply with it. > > Fixes: d31d7cb1460c ("drm/i915: Support for creating write combined type > vmaps") > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH 7/9] drm: Extract drm_property.[hc]

Hi Daniel, On 17 August 2016 at 21:56, Daniel Vetter wrote: > --- /dev/null > +++ b/include/drm/drm_property.h > +#ifndef __DRM_PROPERTY_H__ > +#define __DRM_PROPERTY_H__ > + > +#include > +#include > +#include > + Add the following fwd declaration since we use a

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

On 03/08/2016 17:05, Dave Gordon wrote: On 03/08/16 16:45, Chris Wilson wrote: On Wed, Aug 03, 2016 at 04:36:46PM +0100, Dave Gordon wrote: The parallel execution test in gem_exec_nop chooses a pessimal distribution of work to multiple engines; specifically, it round-robins one batch to each

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Sync against the GuC log buffer flush work item on system suspend

On 8/18/2016 4:25 PM, Imre Deak wrote: On to, 2016-08-18 at 09:15 +0530, Goel, Akash wrote: On 8/17/2016 9:07 PM, Goel, Akash wrote: On 8/17/2016 6:41 PM, Imre Deak wrote: On ke, 2016-08-17 at 18:15 +0530, Goel, Akash wrote: On 8/17/2016 5:11 PM, Chris Wilson wrote: On Wed, Aug 17,

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Sync against the GuC log buffer flush work item on system suspend

On to, 2016-08-18 at 16:54 +0530, Goel, Akash wrote: > > On 8/18/2016 4:25 PM, Imre Deak wrote: > > On to, 2016-08-18 at 09:15 +0530, Goel, Akash wrote: > > > > > > On 8/17/2016 9:07 PM, Goel, Akash wrote: > > > > > > > > > > > > On 8/17/2016 6:41 PM, Imre Deak wrote: > > > > > On ke,

Re: [Intel-gfx] [PATCH 7/9] drm: Extract drm_property.[hc]

On Thu, Aug 18, 2016 at 12:11:35PM +0100, Emil Velikov wrote: > Hi Daniel, > > On 17 August 2016 at 21:56, Daniel Vetter wrote: > > --- /dev/null > > +++ b/include/drm/drm_property.h > > > +#ifndef __DRM_PROPERTY_H__ > > +#define __DRM_PROPERTY_H__ > > + > > +#include >

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Convert intel_crt to use atomic state

On Tue, Aug 09, 2016 at 05:04:07PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_crt.c | 12 +++- > 1 file changed, 7 insertions(+), 5

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Sync against the GuC log buffer flush work item on system suspend

On 8/18/2016 6:29 PM, Imre Deak wrote: On to, 2016-08-18 at 16:54 +0530, Goel, Akash wrote: On 8/18/2016 4:25 PM, Imre Deak wrote: On to, 2016-08-18 at 09:15 +0530, Goel, Akash wrote: On 8/17/2016 9:07 PM, Goel, Akash wrote: On 8/17/2016 6:41 PM, Imre Deak wrote: On ke, 2016-08-17 at

Re: [Intel-gfx] [PATCH 12/15] drm/i915: Convert intel_lvds to use atomic state

On Tue, Aug 09, 2016 at 05:04:11PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_lvds.c | 22 ++ > 1 file changed, 10

[Intel-gfx] [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf

If userspace is asynchronously streaming into the batch or other execobjects, we may not flush those writes along with a change in cache domain (as there is no change). Therefore those writes may end up in internal chipset buffers and not visible to the GPU upon execution. We must issue a flush

[Intel-gfx] [PATCH 2/2] agp/intel: Flush chipset writes after updating a single PTE

After we update one PTE for a page, the caller expects to be able to immediately use that through a GGTT read/write. To comply with the callers expectations we therefore need to flush the chipset buffers before returning. Reported-by: Matti Hämäläinen Fixes: d6473f566417

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Remove unused mode_set hook from encoder

On Tue, Aug 09, 2016 at 05:04:02PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_drv.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Pass atomic state to crtc enable/disable functions

On Tue, Aug 09, 2016 at 05:04:01PM +0200, Maarten Lankhorst wrote: > This is required for supporting nonblocking modesets. Iterating over > the connector list will no longer be allowed when we don't hold > connection_mutex, so we have to use the atomic state. > > Fix disable_noatomic by

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Convert intel_sdvo to use atomic state

On Tue, Aug 09, 2016 at 05:04:10PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_sdvo.c | 27 +++ > 1 file changed, 11

Re: [Intel-gfx] [PATCH 13/15] drm/i915: Convert intel_dp_mst to use atomic state

On Tue, Aug 09, 2016 at 05:04:12PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_dp_mst.c | 48 > ++--- > 1 file changed, 18 insertions(+), 30 deletions(-) > > diff --git

Re: [Intel-gfx] [PATCH 05/15] drm/i915: Pass crtc_state and connector_state to encoder functions

On Tue, Aug 09, 2016 at 05:04:04PM +0200, Maarten Lankhorst wrote: > This is mostly code churn, with exception of a few places: > - intel_display.c has changes in intel_sanitize_encoder > - intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post_disable, > and required a function change.

Re: [Intel-gfx] [PATCH 06/15] drm/i915: Make encoder->compute_config take the connector state

On Tue, Aug 09, 2016 at 05:04:05PM +0200, Maarten Lankhorst wrote: > Some places iterate over connector_state to find the right > connector, pass it along as argument. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter >

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf

== Series Details == Series: series starting with [1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf URL : https://patchwork.freedesktop.org/series/11266/ State : success == Summary == Series 11266v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

Em Qui, 2016-08-18 às 09:21 +0100, Chris Wilson escreveu: > Only fbc1 is tied to using a fence. Later iterations of fbc are more > flexible and allow operation on unfenced frontbuffers. But then we'll lose GTT tracking - which we currently rely on - and I'm 87.5% sure we'll need to implement some

[Intel-gfx] [PATCH v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence

If we cannot release the fence (for example if someone is inexplicably trying to write into a tiled framebuffer that is currently pinned to the display! *cough* kms_frontbuffer_tracking *cough*) fallback to using the page-by-page pwrite/pread interface, rather than fail the syscall entirely.

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Remove unused loop from intel_dp_mst_compute_config

On Tue, Aug 09, 2016 at 05:04:06PM +0200, Maarten Lankhorst wrote: > conn_state is passed as argument now, if anything required conn_state > they can get it without having to look it up. Commit message seems off, this has been dead code before. It seems to be duct-tape from before we had a proper

Re: [Intel-gfx] [PATCH 01/15] drm/i915: handle DP_MST correctly in bxt_get_dpll

On Tue, Aug 09, 2016 at 05:04:00PM +0200, Maarten Lankhorst wrote: > No idea if it supports it, but this is the minimum required from get_dpll. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 10 -- > 1 file

  1   2   >