[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Convert prime dma-buf <-> handle to rhashtable (rev2)

== Series Details == Series: drm: Convert prime dma-buf <-> handle to rhashtable (rev2) URL : https://patchwork.freedesktop.org/series/12787/ State : warning == Summary == Series 12787v2 drm: Convert prime dma-buf <-> handle to rhashtable

[Intel-gfx] [PATCH] drm: Convert prime dma-buf <-> handle to rbtree

Currently we use a linear walk to lookup a handle and return a dma-buf, and vice versa. A long overdue TODO task is to convert that to a hashtable. Since the initial implementation of dma-buf/prime, we now have resizeable hashtables we can use (and now a future task is to RCU enable the lookup!).

Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: Broxton decoupled MMIO

On 26/09/2016 12:08, Paneri, Praveen wrote: On 9/23/2016 3:19 PM, Tvrtko Ursulin wrote: Hi, On 19/09/2016 18:15, Praveen Paneri wrote: [snip] + enum forcewake_domains intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv, i915_reg_t reg, unsigned

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Try to print INSTDONE bits for all slice/subslice

On 16-09-15 17:30:10, Mika Kuoppala wrote: Imre Deak writes: From: Ben Widawsky v2: (Imre) - Access only subslices that are known to exist. - Reset explictly the MCR selector to slice/sub-slice ID 0 after the readout. - Use the subslice

Re: [Intel-gfx] [PATCH] drm/i915: don't report compression when fbc disabled

Em Qui, 2016-09-22 às 14:19 +0530, vathsala nagaraju escreveu: > when i915_fbc_status is read while fbc is disabled, > it reports compressing to be true, which is confusing. > report compressing only when fbc is enabled. > > Signed-off-by: vathsala nagaraju > --- >  

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for SKL/KBL watermark fixes (rev3)

Em Qui, 2016-09-22 às 21:49 +, Patchwork escreveu: > == Series Details == > > Series: SKL/KBL watermark fixes (rev3) > URL   : https://patchwork.freedesktop.org/series/12082/ > State : warning > > == Summary == > > Series 12082v3 SKL/KBL watermark fixes >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: add a few missing platform tags to workaround tags

Em Seg, 2016-09-26 às 15:07 +0300, Jani Nikula escreveu: > Cc: Paulo Zanoni > Signed-off-by: Jani Nikula Reviewed-by: Paulo Zanoni > --- >  drivers/gpu/drm/i915/intel_guc_loader.c | 2 +- >  

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: add a few missing platform tags to workaround tags

Em Seg, 2016-09-26 às 13:20 +, Patchwork escreveu: > == Series Details == > > Series: series starting with [1/2] drm/i915: add a few missing > platform tags to workaround tags > URL   : https://patchwork.freedesktop.org/series/12925/ > State : warning > > == Summary == > > Series 12925v1

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: drm: Per-plane rotation etc.

== Series Details == Series: drm: drm: Per-plane rotation etc. URL : https://patchwork.freedesktop.org/series/12938/ State : warning == Summary == Series 12938v1 drm: drm: Per-plane rotation etc. https://patchwork.freedesktop.org/api/1.0/series/12938/revisions/1/mbox/ Test gem_exec_gttfill:

Re: [Intel-gfx] [PATCH v2 00/16] drm: drm: Per-plane rotation etc.

On Mon, Sep 26, 2016 at 12:30 PM, wrote: > From: Ville Syrjälä > > Another, rebased, version of my earlier series [1] to add the per-plane > rotation property. One thing holding back the previous version was the > weird regression on

Re: [Intel-gfx] [PATCH v2 00/16] drm: drm: Per-plane rotation etc.

On Mon, Sep 26, 2016 at 07:30:45PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Another, rebased, version of my earlier series [1] to add the per-plane > rotation property. One thing holding back the previous version was the > weird

[Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests

Some of the Intel platforms have odd numbers of LUT entries and we need to tests a couple of values around the expected result. Bring back the CRC equal function we need that doesn't trigger an assert right away, while we still assert if we can't find a correct result in the outter loop. v2:

[Intel-gfx] [PATCH v2 13/15] drm/i915: Use & instead if == to check for rotations

From: Ville Syrjälä Using == to check for 180 degree rotation only works as long as the reflection bits aren't set. That will change soon enough for CHV, so let's stop doing things the wrong way. v2: Drop the BIT() Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 10/15] drm/msm/mdp5: Advertize 180 degree rotation

From: Ville Syrjälä Since the hardware can apparently do both X and Y reflection, we can advertize also 180 degree rotation as thats just X+Y reflection. v2: Drop the BIT() Cc: Rob Clark Cc: Jilai Wang Cc: Archit

[Intel-gfx] [PATCH v2 15/15] drm/i915: Add horizontal mirroring support for CHV pipe B planes

From: Ville Syrjälä The primary and sprite planes on CHV pipe B support horizontal mirroring. Expose it to the world. Sadly the hardware ignores the mirror bit when the rotate bit is set, so we'll have to reject the 180+X case. v2: Drop the BIT() Signed-off-by:

[Intel-gfx] [PATCH v2 12/15] drm: RIP mode_config->rotation_property

From: Ville Syrjälä Now that all drivers have been converted over to the per-plane rotation property, we can just nuke the global rotation property. v2: Rebase due to BIT(),__builtin_ffs() & co. Deal with superfluous code shuffling Signed-off-by: Ville

[Intel-gfx] [PATCH v2 14/15] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

From: Ville Syrjälä Move the plane control register rotation setup away from the coordinate munging code. This will result in neater looking code once we add reflection support for CHV. v2: Drop the BIT(), drop some usless parens, Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v3 11/15] drm/i915: Use the per-plane rotation property

From: Ville Syrjälä On certain platforms not all planes support the same set of rotations/reflections, so let's use the per-plane property for this. This is already a problem on SKL when we use the legay cursor plane as it only supports 0|180 whereas the universal

[Intel-gfx] [PATCH v2 09/15] drm/msm/mdp5: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Rob Clark Cc: Jilai Wang Cc: Archit Taneja

[Intel-gfx] [PATCH v2 01/15] drm: Add drm_rotation_90_or_270()

From: Ville Syrjälä We have intel_rotation_90_or_270() in i915 to check if the rotation is 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move the helper into a central place and use it everwhere. v2: Drop the BIT() Convert all new

[Intel-gfx] [PATCH v2 00/16] drm: drm: Per-plane rotation etc.

From: Ville Syrjälä Another, rebased, version of my earlier series [1] to add the per-plane rotation property. One thing holding back the previous version was the weird regression on omap, but apparently I managed to fix it (see [2]). msm and omap still lack

[Intel-gfx] [PATCH v2 04/15] drm/arm: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers

[Intel-gfx] [PATCH 02/15] drm/atomic: Reject attempts to use multiple rotation angles at once

From: Ville Syrjälä The rotation property should only accept exactly one rotation angle at once. Let's reject attempts to set none or multiple angles. Testcase: igt/kms_rotation_crc/bad-rotation Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v3 05/15] drm/atmel-hlcdc: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Propagate error upwards (Boris) v3: Drop the BIT() Cc: Boris Brezillon Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 06/15] drm/omap: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

From: Ville Syrjälä 0 isn't a valid rotation property value, so let's set the initial value of the property to BIT(DRM_ROTATE_0) instead. v2: Drop the BIT() Cc: Tomi Valkeinen Cc: Rob Clark Signed-off-by: Ville

[Intel-gfx] [PATCH v2 07/15] drm/omap: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Not sure I got the annoying crtc rotation_property handling right. Might work, or migth not. v2: Drop the BIT() Don't create rotation

[Intel-gfx] [PATCH v2 08/15] drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

From: Ville Syrjälä 0 isn't a valid rotation property value, so let's set the initial value of the property to BIT(DRM_ROTATE_0) instead. In the same vein, we must always have at leat one angle as part of set of supported rotation bits, so let's include

[Intel-gfx] [PATCH v3 03/15] drm: Add support for optional per-plane rotation property

From: Ville Syrjälä Not all planes on the system may support the same rotations/reflections, so make it possible to create a separate property for each plane. This way userspace gets told exactly which rotations/reflections are possible for each plane. v2: Add

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix HDMI DPLL configuration

== Series Details == Series: drm/i915/bxt: Fix HDMI DPLL configuration URL : https://patchwork.freedesktop.org/series/12930/ State : failure == Summary == Series 12930v1 drm/i915/bxt: Fix HDMI DPLL configuration https://patchwork.freedesktop.org/api/1.0/series/12930/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix HDMI DPLL configuration

On Mon, 26 Sep 2016, Imre Deak wrote: > a277ca7dc01d should've been a no-functional-change commit, but it > removed the initialization of the dpll_hw_state for HDMI outputs, > resulting in state mismatches and a failed modeset with blank > screen. Fix this by reinstating the

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

On Tue, 06 Sep 2016, Jim Bride wrote: > Ville wrote: >> On Thu, Aug 18, 2016 at 05:11:31PM -0700, Anusha Srivatsa wrote: >> > Change intel_dp_mst_mode_valid() to use available link bandwidth >> > rather than the link's maximum supported bandwidth to evaluate whether

[Intel-gfx] [PATCH] drm/i915/bxt: Fix HDMI DPLL configuration

a277ca7dc01d should've been a no-functional-change commit, but it removed the initialization of the dpll_hw_state for HDMI outputs, resulting in state mismatches and a failed modeset with blank screen. Fix this by reinstating the dpll_hw_state initialization. Fixes: a277ca7dc01d ("drm/i915: Split

Re: [Intel-gfx] [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

Hi Is there any chance this could be removed from the upcoming drm-4.9 pull, at least until this issue has been fixed Regards Mike On 21 September 2016 at 12:34, Mike Lothian wrote: > I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll > attach the info

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Code cleanup to use dev_priv and INTEL_GEN

On Fri, 16 Sep 2016, Manasi Navare wrote: > Replace dev with dev_priv and INTEL_INFO with INTEL_GEN Patches like this could easily sent separately, or at the very least as the first patches in the series. Then we could have merged this already. Now it conflicts, please

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: Remove the link rate and lane count loop in compute config

On Fri, 16 Sep 2016, Manasi Navare wrote: > While configuring the pipe during modeset, it should use > max clock and max lane count and reduce the bpp until > the requested mode rate is less than or equal to > available link BW. > This is required to pass DP Compliance.

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

On Fri, 16 Sep 2016, Manasi Navare wrote: > According to the DisplayPort Spec, in case of Clock Recovery failure > the link training sequence should fall back to the lower link rate > followed by lower lane count until CR succeeds. > On CR success, the sequence proceeds

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: add a few missing platform tags to workaround tags

== Series Details == Series: series starting with [1/2] drm/i915: add a few missing platform tags to workaround tags URL : https://patchwork.freedesktop.org/series/12925/ State : warning == Summary == Series 12925v1 Series without cover letter

Re: [Intel-gfx] [PATCH 0/5] drm/i915/skl: drop pre-production stepping workarounds

On Thu, 22 Sep 2016, Paulo Zanoni wrote: > Em Sex, 2016-09-16 às 16:59 +0300, Jani Nikula escreveu: >> Only production steppings are supported, drop workarounds for >> anything >> else. The series is split by revision so we can bikeshed if there are >> steppings some

[Intel-gfx] [PATCH 2/2] drm/i915/skl: tell the user about pre-production hardware

From: Paulo Zanoni We just removed the implementation for all the pre-production workarounds, so now tell the user that we expect his machine to not work properly. Also convert this to DRM_ERROR so we can more easily spot these problems in bug reports and CI/QA runs.

[Intel-gfx] [PATCH 1/2] drm/i915: add a few missing platform tags to workaround tags

Cc: Paulo Zanoni Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_guc_loader.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c

Re: [Intel-gfx] [PATCH] drm/i915/audio: extend get_saved_enc() to support more scenarios

Thanks. Unless there's a trivial quick fix, I expect a revert first. BR, Jani. On Mon, 26 Sep 2016, "Yang, Libin" wrote: > Yes, I see. I will co-work with DK to fix the issue. > > Regards, > Libin > > >> -Original Message- >> From: Jani Nikula

Re: [Intel-gfx] [PATCH] drm/i915/audio: extend get_saved_enc() to support more scenarios

Yes, I see. I will co-work with DK to fix the issue. Regards, Libin > -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Monday, September 26, 2016 4:39 PM > To: Yang, Libin ; libin.y...@linux.intel.com; intel- >

Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: Broxton decoupled MMIO

On 9/23/2016 3:19 PM, Tvrtko Ursulin wrote: Hi, On 19/09/2016 18:15, Praveen Paneri wrote: Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles and avoids frequent software forcewake. I would like to see a sentence or two on how it works

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 8700"

== Series Details == Series: series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 8700" URL : https://patchwork.freedesktop.org/series/12920/ State : warning == Summary == Series 12920v1 Series without cover letter

Re: [Intel-gfx] cerryview sd card problem

On Mon, Sep 26, 2016 at 11:57:04AM +0300, Jani Nikula wrote: > On Wed, 21 Sep 2016, Giacomo Comes wrote: > > Hi, > > I hope this is the appropriate place to ask what follows. > > If not please point me to the right place. > > > > I have a couple of cerryview systems > > (Acer

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED

On Mon, Sep 26, 2016 at 09:23:55AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED > URL : https://patchwork.freedesktop.org/series/12918/ > State : warning > > == Summary == > > Series 12918v1 drm/i915: Allow PCH

Re: [Intel-gfx] [PATCH 32/38] drm/i915: Defer request emission

On Mon, Sep 26, 2016 at 12:06:19PM +0300, Joonas Lahtinen wrote: > On ma, 2016-09-26 at 10:04 +0100, Chris Wilson wrote: > > On Mon, Sep 26, 2016 at 11:53:05AM +0300, Joonas Lahtinen wrote: > > > > > > On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote: > > > > > > > > Move the actual emission

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED

== Series Details == Series: drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED URL : https://patchwork.freedesktop.org/series/12918/ State : warning == Summary == Series 12918v1 drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED

[Intel-gfx] [PATCH 3/3] drm/i915: Add spurious CRT DMI match for Intel DZ77BH-55K

From: Ville Syrjälä Intel DZ77BH-55K board doest't have a physical VGA connector, and yet it always detects that something is connected there. Add it to the DMI blacklist to ignore the spurious detection results. Allows me to drop 'video=VGA-1:d' from my kernel

[Intel-gfx] [PATCH 1/3] Revert "Skip intel_crt_init for Dell XPS 8700"

From: Ville Syrjälä This reverts commit 10b6ee4a87811a110cb01eaca01eb04da6801baf. According to [1] Dell XPS8700 VBT says 'int_crt_support 0', so thanks to commit e4abb733bb72 ("drm/i915: Check VBT for CRT port presence on HSW/BDW") we no longer need to blacklist

[Intel-gfx] [PATCH 2/3] drm/i915: Register shadow VGA even when it produces spurious detection results

From: Ville Syrjälä Having a shadow VGA connector is useful for testing purposes. We currently skip registering the connector on machines where the CRT detect falsely reports it as connected. Let's instead move the the blacklist check to the detect callback (and

Re: [Intel-gfx] [PATCH 32/38] drm/i915: Defer request emission

On ma, 2016-09-26 at 10:04 +0100, Chris Wilson wrote: > On Mon, Sep 26, 2016 at 11:53:05AM +0300, Joonas Lahtinen wrote: > > > > On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote: > > > > > > Move the actual emission of the request (the closing breadcrumb) from > > > i915_add_request() to the

Re: [Intel-gfx] [PATCH 32/38] drm/i915: Defer request emission

On Mon, Sep 26, 2016 at 11:53:05AM +0300, Joonas Lahtinen wrote: > On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote: > > Move the actual emission of the request (the closing breadcrumb) from > > i915_add_request() to the submit callback. (It can be moved later when > > required.) This allows

Re: [Intel-gfx] [PATCH 02/38] drm/i915: Stop the machine whilst capturing the GPU crash dump

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > The error state is purposefully racy as we expect it to be called at any > time and so have avoided any locking whilst capturing the crash dump. > However, with multi-engine GPUs and multiple CPUs, those races can > manifest into OOPSes as we

Re: [Intel-gfx] cerryview sd card problem

On Wed, 21 Sep 2016, Giacomo Comes wrote: > Hi, > I hope this is the appropriate place to ask what follows. > If not please point me to the right place. > > I have a couple of cerryview systems > (Acer Aspire R11 and Intel compute stick STK1AW32SC) on which > I run linux (openSUSE

Re: [Intel-gfx] [PATCH 36/38] drm/i915: Enable multiple timelines

On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote: > With the infrastructure converted over to tracking multiple timelines in > the GEM API whilst preserving the efficiency of using a single execution > timeline internally, we can now assign a separate timeline to every > context with

Re: [Intel-gfx] [PATCH 32/38] drm/i915: Defer request emission

On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote: > Move the actual emission of the request (the closing breadcrumb) from > i915_add_request() to the submit callback. (It can be moved later when > required.) This allows us to defer the allocation of the global_seqno > from request construction

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: extend get_saved_enc() to support more scenarios

== Series Details == Series: drm/i915/audio: extend get_saved_enc() to support more scenarios URL : https://patchwork.freedesktop.org/series/12917/ State : success == Summary == Series 12917v1 drm/i915/audio: extend get_saved_enc() to support more scenarios

Re: [Intel-gfx] [PATCH 28/38] drm/i915: Queue the idling context switch after all other timelines

On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote: > +__maybe_unused static bool is_kernel_context(struct drm_i915_private > *dev_priv) __maybe_unused definitely most definitely does not belong here. Need solve the GEM_BUG_ON otherwise. Also, "is_in_kernel_context" as you have

Re: [Intel-gfx] [PATCH] drm/i915/audio: extend get_saved_enc() to support more scenarios

I will NAK all further DP MST audio patches until https://bugs.freedesktop.org/show_bug.cgi?id=97907 is fixed. BR, Jani. On Mon, 26 Sep 2016, "Yang, Libin" wrote: > Add DK, Jim and Jeeja > > Regards, > Libin > > >> -Original Message- >> From:

[Intel-gfx] [PATCH] drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED

From: Ville Syrjälä DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it forbidden to set it for LVDS/CRT as well. So let's also set it on CRT to make it possible to share the DPLL between HDMI and CRT. What that bit apparently does is enable the

Re: [Intel-gfx] [PATCH] drm/i915/audio: extend get_saved_enc() to support more scenarios

Add DK, Jim and Jeeja Regards, Libin > -Original Message- > From: libin.y...@linux.intel.com [mailto:libin.y...@linux.intel.com] > Sent: Monday, September 26, 2016 4:21 PM > To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; > ville.syrj...@linux.intel.com; Vetter, Daniel

[Intel-gfx] [PATCH] drm/i915/audio: extend get_saved_enc() to support more scenarios

From: Libin Yang When bootup, audio driver may not know it is MST or not. The audio driver will poll all the port & pipe combinations in either MST or Non-MST mode. get_saved_enc() should handle this situation. Signed-off-by: Libin Yang

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

On Tue, 20 Sep 2016, Dhinakaran Pandiyan wrote: > 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

Re: [Intel-gfx] [PATCH 26/38] drm/i915: Restore nonblocking awaits for modesetting

CC'ing Maarten to A-b or R-b. On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote: > @@ -14615,31 +14641,25 @@ intel_prepare_plane_fb(struct drm_plane *plane, >    * This should only fail upon a hung GPU, in which case we >    * can safely continue. >    */ >

Re: [Intel-gfx] [PATCH 24/38] drm/i915: Move GEM activity tracking into a common struct reservation_object

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > +static struct intel_engine_cs * > +last_write_engine(struct drm_i915_gem_object *obj) This function is repeated below, better move it to header as __i915_gem_obj_last_write_engine? I'd say there is not an ABI change now as non-i915 fences

Re: [Intel-gfx] [PATCH 12/38] drm/i915: Reuse the active golden render state batch

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > @@ -143,88 +149,126 @@ static int render_state_setup(struct render_state *so) >   } >   >   OUT_BATCH(d, i, MI_BATCH_BUFFER_END); > - so->aux_batch_size = (i * sizeof(u32)) - so->aux_batch_offset; > - > + so->aux_size = i *

Re: [Intel-gfx] [PATCH 3/6] drm/i915: keep declarations in i915_drv.h

On to, 2016-09-22 at 13:50 +0200, Daniel Vetter wrote: > we also need to split up our headers I think, and I plan to start doing > that when extracting bits and pieces from intel_display.c. In drm core at > least having 1:1 between headers and source files seems to work rather > well. +1 on that,

[Intel-gfx] log splat from Intel DRM driver on resume

When I resume my desktop from suspend, the following shows up in the log. Running 4.8.0-rc6 (net-next branch).dme Everything appears to be working ok. [148349.793696] PM: Syncing filesystems ... done. [148350.599336] PM: Preparing system for sleep (mem) [148350.599623] Freezing user space

Re: [Intel-gfx] log splat from Intel DRM driver on resume

On Fri, 23 Sep 2016, Stephen Hemminger wrote: > When I resume my desktop from suspend, the following shows up in the log. > Running 4.8.0-rc6 (net-next branch).dme Please clarify what that is. Please file a bug at [1] and attach full dmesg from the boot, with