[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,01/23] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

== Series Details == Series: series starting with [CI,01/23] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit URL : https://patchwork.freedesktop.org/series/10523/ State : failure == Summary == Series 10523v1 Series without cover letter

[Intel-gfx] ✗ Ro.CI.BAT: warning for 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

== Series Details == Series: 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain URL : https://patchwork.freedesktop.org/series/10522/ State : warning == Summary == Series 10522v1 2016y-07m-14d-21h-13m-02s UTC: locking dependency:

[Intel-gfx] [PATCH 1/2] drm/i915: Fix copy_to_user usage for pipe_crc

Copy to user return the number of bytes it couldn't write and zero on success. So any number different than 0 should be considered a fault, not only when it doesn't write the full size. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 4 +--- 1 file

[Intel-gfx] [PATCH 2/2] drm/i915: Fix the return value of pipe crc read function.

A read(fd, buf, len) function should return the number of bytes read. In our case we need to return the number of bytes we copy to user, instead of returning the number of bytes we read internally. It was really strange when I saw i-g-t test case using len '54' but getting '56' as return. First

[Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

DP MST provides the capability to send multiple video and audio streams via one single port. This requires the API's between i915 and audio drivers to distinguish between audio capable displays connected to a port. This patch adds this support via an additional parameter 'int dev_id'. The existing

[Intel-gfx] DP audio API changes for identifying displays connected to a port

An additional parameter has been added to the API's between i915 and audio drivers to identify display devices that can be connected to the same port. Currently only the port identity is being shared, but this is not sufficient as multiple displays can be driven from the same port (E.g. DP MST).

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move audio_connector to intel_encoder

Add Takashi Regards, Libin > -Original Message- > From: Pandiyan, Dhinakaran > Sent: Wednesday, August 3, 2016 9:47 AM > To: intel-gfx@lists.freedesktop.org > Cc: cp...@redhat.com; ville.syrj...@linux.intel.com; Yang, Libin > ; Pandiyan, Dhinakaran >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: start adding dp mst audio

Add Takashi Regards, Libin > -Original Message- > From: Pandiyan, Dhinakaran > Sent: Wednesday, August 3, 2016 9:47 AM > To: intel-gfx@lists.freedesktop.org > Cc: cp...@redhat.com; ville.syrj...@linux.intel.com; Yang, Libin > ; Libin Yang

Re: [Intel-gfx] Prep. for DP audio MST support

Add Takashi who is the audio driver maintainer. Dhinakaran is working on gfx driver support for DP MST. > -Original Message- > From: Pandiyan, Dhinakaran > Sent: Wednesday, August 3, 2016 9:47 AM > To: intel-gfx@lists.freedesktop.org > Cc: cp...@redhat.com;

[Intel-gfx] [PATCH 3/3] drm/i915: Fix enc_to_dig_port for MST encoders

When a MST encoder is passed to enc_to_dig_port(), the container_of() macro does not return the digital port. Handle this by returning the member "primary" in "struct intel_dp_mst_encoder" Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_drv.h |

[Intel-gfx] [PATCH 2/3] drm/i915: Move audio_connector to intel_encoder

With DP MST, a digital_port can carry more than one audio stream. Hence, more than one audio_connector needs to be attached to intel_digital_port in such cases. However, each stream is associated with an unique encoder. So, instead of creating an array of audio_connectors per port, move

[Intel-gfx] [PATCH 1/3] drm/i915: start adding dp mst audio

From: Libin Yang (This patch is developed by Dave Airlie originally) This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio

[Intel-gfx] Prep. for DP audio MST support

This series lays the groundwork for more DP MST audio work that will follow. Patch 1 got possibly reverted because Patch 3 was missing. The APIs between i915 and audio drivers have to modified so that the audio drivers can identify different displays connected to a port. The changes introduced in

Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

On Tue, 2016-08-02 at 20:48 +, Vivi, Rodrigo wrote: > On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote: [...] > > Why are you deleting old versions? > > Mainly to keep it clean. OSVs pack that entire repo, I don't want i915 > taking unnecessary space from final users. Any filename

Re: [Intel-gfx] [PATCH v5 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

On Tue, Aug 02, 2016 at 02:52:54PM -0400, Lyude wrote: > Now that we can hook into update_crtcs and control the order in which we > update CRTCs at each modeset, we can finish the final step of fixing > Skylake's watermark handling by performing DDB updates at the same time > as plane updates and

[Intel-gfx] [PATCH v6 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

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 however, is the mysterious issue of underruns causing

[Intel-gfx] [PATCH v6 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org

[Intel-gfx] [PATCH v6 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[Intel-gfx] [PATCH v6 0/6] Finally fix watermarks

Latest version of https://patchwork.freedesktop.org/patch/102581/ . Lyude (5): drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Update plane watermarks atomically during plane updates drm/i915/skl: Ensure pipes with changed wms get added to the state drm/i915: Move

[Intel-gfx] [PATCH v6 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[Intel-gfx] [PATCH v6 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[Intel-gfx] [PATCH v6 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

Re: [Intel-gfx] [PATCH v5 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

On Tue, Aug 02, 2016 at 02:52:53PM -0400, Lyude wrote: > Since we have to write ddb allocations at the same time as we do other > plane updates, we're going to need to be able to control the order in > which we execute modesets on each pipe. The easiest way to do this is to > just factor this

[Intel-gfx] [CI 18/23] drm/i915/ringbuffer: Specialise SNB+ request emission for semaphores

As gen6_emit_request() only differs from i9xx_emit_request() when semaphores are enabled, only use the specialised vfunc in that scenario. v2: Reorder semaphore init so as to keep engine->emit_request default vfunc selection compact. Signed-off-by: Chris Wilson Link:

[Intel-gfx] [CI 22/23] drm/i915: Simplify calling engine->sync_to

Since requests can no longer be generated as a side-effect of intel_ring_begin(), we know that the seqno will be unchanged during ring-emission. This predicatablity then means we do not have to check for the seqno wrapping around whilst emitting the semaphore for engine->sync_to(). Signed-off-by:

[Intel-gfx] [CI 17/23] drm/i915: Reuse legacy breadcrumbs + tail emission

As GEN6+ is now a simple variant on the basic breadcrumbs + tail write, reuse the common code. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [CI 23/23] drm/i915: Rename engine->semaphore.sync_to, engine->sempahore.signal locals

In order to be more consistent with the rest of the request construction and ring emission, use the common names for the ring and request. Rather than using signaler_req, waiter_req, and intel_ring *wait, we use plain req and ring. Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [CI 19/23] drm/i915: Remove duplicate golden render state init from execlists

Now that we use the same vfuncs for emitting the batch buffer in both execlists and legacy, the golden render state initialisation is identical between both. v2: gcc wants so.ggtt_offset initialised (even though it is not used) Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [CI 12/23] drm/i915: Convert engine->write_tail to operate on a request

If we rewrite the I915_WRITE_TAIL specialisation for the legacy ringbuffer as submitting the request onto the ringbuffer, we can unify the vfunc with both execlists and GuC in the next patch. v2: Drop the modulus from the I915_WRITE_TAIL as it is currently being applied in intel_ring_advance()

[Intel-gfx] [CI 08/23] drm/i915: Reduce engine->emit_flush() to a single mode parameter

Rather than passing a complete set of GPU cache domains for either invalidation or for flushing, or even both, just pass a single parameter to the engine->emit_flush to determine the required operations. engine->emit_flush(GPU, 0) -> engine->emit_flush(EMIT_INVALIDATE) engine->emit_flush(0, GPU)

[Intel-gfx] [CI 02/23] drm/i915: Rename request->ringbuf to request->ring

Now that we have disambuigated ring and engine, we can use the clearer and more consistent name for the intel_ringbuffer pointer in the request. @@ struct drm_i915_gem_request *r; @@ - r->ringbuf + r->ring Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [CI 07/23] drm/i915: Remove obsolete engine->gpu_caches_dirty

Space for flushing the GPU cache prior to completing the request is preallocated and so cannot fail - the GPU caches will always be flushed along with the completed request. This means we no longer have to track whether the GPU cache is dirty between batches like we had to with the

[Intel-gfx] [CI 04/23] drm/i915: Rename struct intel_ringbuffer to struct intel_ring

The state stored in this struct is not only the information about the buffer object, but the ring used to communicate with the hardware. Using buffer here is overly specific and, for me at least, conflates with the notion of buffer objects themselves. s/struct intel_ringbuffer/struct intel_ring/

[Intel-gfx] [CI 14/23] drm/i915: Unify request submission

Move request submission from emit_request into its own common vfunc from i915_add_request(). v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing v3: Rename a few functions to match. v4: Reenable execlists submission after disabling guc. v5: Be aware that everyone calls

[Intel-gfx] [CI 06/23] drm/i915: Rename intel_pin_and_map_ring()

For more consistent oop-naming, we would use intel_ring_verb, so pick intel_ring_pin() and intel_ring_unpin(). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [CI 09/23] drm/i915: Simplify request_alloc by returning the allocated request

If is simpler and leads to more readable code through the callstack if the allocation returns the allocated struct through the return value. The importance of this is that it no longer looks like we accidentally allocate requests as side-effect of calling certain functions. Signed-off-by: Chris

[Intel-gfx] [CI 05/23] drm/i915: Rename residual ringbuf parameters

Now that we have a clear ring/engine split and a struct intel_ring, we no longer need the stopgap ringbuf names. Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-16-git-send-email-ch...@chris-wilson.co.uk Reviewed-by:

[Intel-gfx] [CI 16/23] drm/i915: Stop passing caller's num_dwords to engine->semaphore.signal()

Rather than pass in the num_dwords that the caller wishes to use after the signal command packet, split the breadcrumb emission into two phases and have both the signal and breadcrumb individiually acquire space on the ring. This makes the interface simpler for the reader, and will simplify for

[Intel-gfx] [CI 21/23] drm/i915: Unify legacy/execlists submit_execbuf callbacks

Now that emitting requests is identical between legacy and execlists, we can use the same function to build up the ring for submitting to either engine. (With the exception of i915_switch_contexts(), but in time that will also be handled gracefully.) Signed-off-by: Chris Wilson

[Intel-gfx] [CI 15/23] drm/i915/lrc: Update function names to match request flow

With adding engine->submit_request, we now have a bunch of functions with similar names used at different stages of the execlist submission. Try a different coat of paint, to hopefully reduce confusion between the requests, intel_engine_cs and the actual execlists submision process.

[Intel-gfx] [CI 10/23] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

Both the ->dispatch_execbuffer and ->emit_bb_start callbacks do exactly the same thing, add MI_BATCHBUFFER_START to the request's ringbuffer - we need only one vfunc. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [CI 13/23] drm/i915: Move the modulus for ring emission to the register write

Space reservation is already safe with respect to the ring->size modulus, but hardware only expects to see values in the range 0...ring->size-1 (inclusive) and so requires the modulus to prevent us writing the value ring->size instead of 0. As this is only required for the register itself, we can

[Intel-gfx] [CI 11/23] drm/i915: Remove intel_ring_get_tail()

Joonas doesn't like the tiny function, especially if I go around making it more complicated and using it elsewhere. To remove that temptation, remove the function! Signed-off-by: Chris Wilson Link:

[Intel-gfx] [CI 20/23] drm/i915: Refactor golden render state emission to unconfuse gcc

GCC was inlining the init and setup functions, but was getting itself confused into thinking that variables could be used uninitialised. If we do the inline for gcc, it is happy! As a bonus we shrink the code. v2: A couple of minor tweaks from Joonas Signed-off-by: Chris Wilson

[Intel-gfx] [CI 01/23] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

Both perform the same actions with more or less indirection, so just unify the code. v2: Add back a few intel_engine_cs locals Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [CI 03/23] drm/i915: Rename intel_context[engine].ringbuf

Perform s/ringbuf/ring/ on the context struct for consistency with the ring/engine split. v2: Kill an outdated error_ringbuf label Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

Re: [Intel-gfx] [PATCH v5 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

On Tue, Aug 02, 2016 at 02:52:52PM -0400, Lyude wrote: > If we're enabling a pipe, we'll need to modify the watermarks on all > other active pipes. Since those pipes won't be added to the state on > their own, we need to add them ourselves. All pipes (crtc's) are already added to the state if we

Re: [Intel-gfx] [PATCH v5 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

On Tue, Aug 02, 2016 at 02:52:51PM -0400, Lyude wrote: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New >

Re: [Intel-gfx] Disable power management on i915

Hello Joonas, Thanks for your answer. It is a test related for this bug: https://bugzilla.kernel.org/show_bug.cgi?id=109051 Best Regards, Adolfo Sanchez -Original Message- From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] Sent: Tuesday, August 02, 2016 1:48 AM To:

Re: [Intel-gfx] [PATCH v5 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

On Tue, Aug 02, 2016 at 02:52:49PM -0400, Lyude wrote: > 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

Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote: > On Sat, 02 Jul 2016, "Vivi, Rodrigo" wrote: > > > > Hi, > > > > Please consider pulling i915 updates to linux-firmware.git > > > > > > The following changes since commit > >

Re: [Intel-gfx] [v5, 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Hi, On 08/02/2016 08:52 PM, cp...@redhat.com wrote: 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] [PATCH v5 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[Intel-gfx] [PATCH v5 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[Intel-gfx] [PATCH v5 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[Intel-gfx] [PATCH v5 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[Intel-gfx] [PATCH v5 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all other active pipes. Since those pipes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Cc: sta...@vger.kernel.org Cc: Ville Syrjälä

[Intel-gfx] [PATCH v5 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

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 however, is the mysterious issue of underruns causing

[Intel-gfx] [PATCH v5 0/6] Finally fix watermarks

Next version of https://patchwork.freedesktop.org/series/10276/ . Notable series-wide changes: - Added the following patches: - "drm/i915/skl: Ensure pipes with changed wms get added to the state" - "drm/i915: Move CRTC updating in atomic_commit into it's own hook" - "drm/i915/skl:

Re: [Intel-gfx] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

On Mon, Aug 1, 2016 at 3:33 PM, Jani Nikula wrote: > On Fri, 15 Jul 2016, Sedat Dilek wrote: >> Hi, >> >> I see the below call-trace with latest d-i-n, guess latest linux-next > > FWIW, "d-i-n" is ambiguous (drm-intel-next vs.

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

On Tue, Aug 02, 2016 at 01:58:51PM +, Yang, Libin wrote: > Hi Ville > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > Sent: Tuesday, August 2, 2016 6:47 PM > > To: libin.y...@linux.intel.com > > Cc: intel-gfx@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

On Tue, Aug 02, 2016 at 05:41:50PM +0200, Maarten Lankhorst wrote: > Op 01-08-16 om 13:48 schreef Ville Syrjälä: > > On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote: > >> Op 29-07-16 om 22:33 schreef Matt Roper: > >>> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

Op 01-08-16 om 13:48 schreef Ville Syrjälä: > On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote: >> Op 29-07-16 om 22:33 schreef Matt Roper: >>> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: >

Re: [Intel-gfx] [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

Daniel Vetter writes: > Hm, I think we should just clean up wiat_req in ->atomic_destroy_state > instead of littering cleanup code all over. But this gets the job done, so > applied. Thanks. It's required for the DRM patch I posted that makes moving the cursor not block on

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

Yes we had the issue of incorrect edid read. But as of now you can go ahead with the revert. I have moved to a different group, so I am not working on this anymore. Regards, Sonika -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Tuesday, August 2, 2016 8:02

Re: [Intel-gfx] [PATCH] drm/i915: Add missing ring_mask to Pineview

On Tue, Aug 02, 2016 at 04:34:25PM +0200, Daniel Vetter wrote: > On Fri, Jul 29, 2016 at 12:10:30PM +0100, Chris Wilson wrote: > > On Fri, Jul 29, 2016 at 10:57:49AM +0200, Daniel Vetter wrote: > > > On Fri, Jul 29, 2016 at 11:42:24AM +0300, Joonas Lahtinen wrote: > > > > On pe, 2016-07-29 at

Re: [Intel-gfx] [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount of cascading failures

They do run separately. It's just that when one fails it does not close the fd and the next cannot open it as master. Is there a mechanism for closing the fd (or any other tidy up on close.failure). As the test runner implements a psudo exception handler it should really have a "final"/"skip"

Re: [Intel-gfx] [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount of cascading failures

On Mon, Aug 01, 2016 at 10:33:17AM +0100, Peter Antoine wrote: > On Mon, 1 Aug 2016, Chris Wilson wrote: > > > On Fri, Jul 29, 2016 at 10:34:36AM +0100, Peter Antoine wrote: > > > If one of the previous tests fails then the following tests fail. > > > This patch means that the following tests do

Re: [Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 02:37:37PM +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote: > > I find that the developers often just specified the numeric value > > when calling a macro which is defined with a parameter for access > > permission. > > As we know,

Re: [Intel-gfx] [PATCH] drm/i915: Add missing ring_mask to Pineview

On Fri, Jul 29, 2016 at 12:10:30PM +0100, Chris Wilson wrote: > On Fri, Jul 29, 2016 at 10:57:49AM +0200, Daniel Vetter wrote: > > On Fri, Jul 29, 2016 at 11:42:24AM +0300, Joonas Lahtinen wrote: > > > On pe, 2016-07-29 at 00:45 +0100, Chris Wilson wrote: > > > > It appears that we never told

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

On Tue, Jul 12, 2016 at 02:39:47PM +0300, David Weinehall wrote: > I'm feeling sorely tempted to treat this as a proper regression, > and simply submit a revert patch, seeing as it slows down resume by > something like 200ms, but seeing as there was mention of a case where > incorrect

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Track active streams also for DP SST

On Fri, Jul 29, 2016 at 11:36:40AM -0700, Jim Bride wrote: > On Fri, Jul 29, 2016 at 02:36:23PM +0300, Ville Syrjälä wrote: > > On Fri, Jul 29, 2016 at 11:22:32AM +0200, Daniel Vetter wrote: > > > On Thu, Jul 28, 2016 at 05:50:41PM +0300, ville.syrj...@linux.intel.com > > > wrote: > > > > From:

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Reject mixing MST and SST/HDMI on the same digital port

On Fri, Jul 29, 2016 at 02:28:26PM +0300, Ville Syrjälä wrote: > On Fri, Jul 29, 2016 at 11:19:18AM +0200, Daniel Vetter wrote: > > On Thu, Jul 28, 2016 at 05:50:40PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > We can't

Re: [Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

On Tue, Aug 02, 2016 at 11:10:46AM +0100, Dave Gordon wrote: > On 21/07/16 18:10, Dave Gordon wrote: > > On 21/07/16 11:38, Tvrtko Ursulin wrote: > > > > > > On 20/07/16 22:07, Rodrigo Vivi wrote: > > > > please kill this _ucode variation that is just a alias to guc > > > > instead > > > > >

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

On Mon, Aug 01, 2016 at 11:18:15PM +0530, Kamble, Sagar A wrote: > Reviewed-by: Sagar Arun Kamble > You're mailer wreaks havoc with your reviewed-by tags. Pleas fix this. > On 6/27/2016 8:10 PM, akash.g...@intel.com wrote: > > From:

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Avoid mixing up SST and MST in DDI setup

On Fri, Jul 29, 2016 at 12:55:20PM +0300, Ville Syrjälä wrote: > On Fri, Jul 29, 2016 at 11:16:19AM +0200, Daniel Vetter wrote: > > On Thu, Jul 28, 2016 at 05:50:39PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > The MST vs.

Re: [Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 02:37:37PM +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote: > > I find that the developers often just specified the numeric value > > when calling a macro which is defined with a parameter for access > > permission. > > As we know,

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

Hi Jani, > -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Tuesday, August 2, 2016 6:53 PM > To: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; > ville.syrj...@linux.intel.com; Vetter, Daniel ; > ti...@suse.de >

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

Hi Ville > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, August 2, 2016 6:47 PM > To: libin.y...@linux.intel.com > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, > Daniel > ;

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Always use cpp==4 for FW_BLC_SELF on 915GM/945GM

On Fri, Jul 29, 2016 at 05:32:32PM +0100, Chris Wilson wrote: > On Fri, Jul 29, 2016 at 05:57:01PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Bspec says: > > "FW_BLC_SELF > > ... > > Programming Note [DevALV] and [DevCST]: When

Re: [Intel-gfx] [PATCH] drm/i915: Warn about aux msg buffer vs. size mismatch

On Thu, Jul 28, 2016 at 10:15:35PM +0200, Daniel Vetter wrote: > On Thu, Jul 28, 2016 at 05:55:04PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > If we have have a buffer, we should also have a size, and vice versa. > > Let's check it

Re: [Intel-gfx] [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

On Sun, Jul 31, 2016 at 12:54:51AM -0700, Keith Packard wrote: > There are two paths into intel_cleanup_plane_fb, the normal completion > path and the failure path. > > In the failure case, intel_cleanup_plane_fb is called before > drm_atomic_helper_swap_state, so any wait_req reference made in >

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Warn about aux msg buffer vs. size mismatch

On Thu, Jul 28, 2016 at 03:20:52PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Warn about aux msg buffer vs. size mismatch > URL : https://patchwork.freedesktop.org/series/10356/ > State : failure > > == Summary == > > Series 10356v1 drm/i915: Warn about aux msg

Re: [Intel-gfx] [PATCH 0/9] drm: Store clipped coordinates in drm_plane_state

On Mon, Aug 01, 2016 at 06:19:02PM +0300, Ville Syrjälä wrote: > On Mon, Aug 01, 2016 at 11:12:05AM -0400, Sean Paul wrote: > > On Tue, Jul 26, 2016 at 12:06 PM, wrote: > > > From: Ville Syrjälä > > > > > > Moving the clipped plane

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Always use cpp==4 for FW_BLC_SELF on 915GM/945GM

On Fri, Jul 29, 2016 at 03:21:00PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Always use cpp==4 for > FW_BLC_SELF on 915GM/945GM > URL : https://patchwork.freedesktop.org/series/10392/ > State : failure > > == Summary == > > Series 10392v1

Re: [Intel-gfx] [PATCH v6 09/10] drm/i915: Update bits per component for display info

On Tue, Aug 02, 2016 at 02:41:25PM +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 02:23:13PM +0300, Mika Kahola wrote: > > On Tue, 2016-07-12 at 15:51 +0200, Daniel Vetter wrote: > > > On Wed, Jul 06, 2016 at 02:04:53PM +0300, Mika Kahola wrote: > > > > DisplayPort branch device may define

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

== Series Details == Series: drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2 URL : https://patchwork.freedesktop.org/series/10511/ State : failure == Summary == Series 10511v1 drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

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

On Fri, 29 Jul 2016, Ville Syrjälä wrote: > On Thu, Jul 28, 2016 at 12:12:27PM -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

Re: [Intel-gfx] [PATCH] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

On Tue, 02 Aug 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The spec was recently fixed to have the correct iboost setting for the > SKL Y/U DP DDI buffer translation table entry 2. Update our tables > to match. > > Cc: David Weinehall

Re: [Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

On Tue, 02 Aug 2016, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote: >> I find that the developers often just specified the numeric value >> when calling a macro which is defined with a parameter for access permission. >> As we know,

[Intel-gfx] [PATCH] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

From: Ville Syrjälä The spec was recently fixed to have the correct iboost setting for the SKL Y/U DP DDI buffer translation table entry 2. Update our tables to match. Cc: David Weinehall Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 0/9] drm/i915: SKL iboost fixes

On Tue, Jul 12, 2016 at 03:59:27PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > While looking into the recent low vs. normal vswing SKL regression, I ended > up going through the iboost handling as well. I spotted several problems > which

Re: [Intel-gfx] [PATCH v6 09/10] drm/i915: Update bits per component for display info

On Tue, Aug 02, 2016 at 02:23:13PM +0300, Mika Kahola wrote: > On Tue, 2016-07-12 at 15:51 +0200, Daniel Vetter wrote: > > On Wed, Jul 06, 2016 at 02:04:53PM +0300, Mika Kahola wrote: > > > DisplayPort branch device may define max supported bits per > > > component. Update display info based on

Re: [Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro,

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0

== Series Details == Series: drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0 URL : https://patchwork.freedesktop.org/series/10505/ State : failure == Summary == Series 10505v1 drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: remove redundant fbc warnings

Merged, thanks for the patch and review. On ti, 2016-08-02 at 12:05 +0100, Matthew Auld wrote: > > > > Test gem_exec_flush: > > Subgroup basic-batch-kernel-default-cmd: > > pass   -> FAIL   (ro-byt-n2820) > https://bugs.freedesktop.org/show_bug.cgi?id=95372 --

[Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability

Re: [Intel-gfx] [PATCH v6 09/10] drm/i915: Update bits per component for display info

On Tue, 2016-07-12 at 15:51 +0200, Daniel Vetter wrote: > On Wed, Jul 06, 2016 at 02:04:53PM +0300, Mika Kahola wrote: > > DisplayPort branch device may define max supported bits per > > component. Update display info based on this value if bpc > > is defined. > > > > v2: cleanup to match the

Re: [Intel-gfx] [PATCH] drm/i915: Protect older gen against intel_gt_init_powersave()

On ti, 2016-08-02 at 13:55 +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 11:15:27AM +0100, Chris Wilson wrote: > > > > In the middle of intel_gt_init_powersave() we have an if-chain that ends > > with a universal else clause to read gen6+ registers. Older platforms > > like Pineview that

Re: [Intel-gfx] [PATCH v6 08/10] drm/i915: Check pixel rate for DP to VGA dongle

On Tue, 2016-07-12 at 15:50 +0200, Daniel Vetter wrote: > On Wed, Jul 06, 2016 at 02:04:52PM +0300, Mika Kahola wrote: > > Filter out a mode that exceeds the max pixel rate setting > > for DP to VGA dongle. This is defined in DPCD register 0x81 > > if detailed cap info i.e. info field is 4 bytes

  1   2   >