Re: [Intel-gfx] [alsa-devel] [PATCH v4 0/3] support DP MST audio

On Tue, Dec 6, 2016 at 8:20 AM, Takashi Iwai wrote: > On Tue, 06 Dec 2016 03:58:21 +0100, > Yang, Libin wrote: >> >> The patchset is based on drm-tip branch in >> git://anongit.freedesktop.org/drm-tip > > I'll review and merge if it's OK. > > Daniel, do you guys have the stable

Re: [Intel-gfx] [PATCH 1/4] drm: Add a new connector atomic property for link status

On Mon, Dec 05, 2016 at 04:27:35PM -0800, Manasi Navare wrote: > At the time userspace does setcrtc, we've already promised the mode > would work. The promise is based on the theoretical capabilities of > the link, but it's possible we can't reach this in practice. The DP > spec describes how the

Re: [Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status

On Mon, Dec 05, 2016 at 12:33:28PM -0800, Manasi Navare wrote: > On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote: > > Hm, tiny new bikeshed: I'd drop the _property postfix here. The function > > name is already really long as-is, and the fact that the link status is > > exposed as a

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: Drop comment on fwif autogeneration

On Mon, Dec 05, 2016 at 06:59:01PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/guc: Drop comment on fwif autogeneration > URL : https://patchwork.freedesktop.org/series/16373/ > State : warning > > == Summary == > > Series 16373v1 drm/i915/guc: Drop comment on fwif

Re: [Intel-gfx] [PATCH] drm/i915/guc: Drop comment on fwif autogeneration

On Tue, Dec 06, 2016 at 12:59:03AM +0100, Srivatsa, Anusha wrote: > >-Original Message- > >From: Hiler, Arkadiusz > >Sent: Monday, December 5, 2016 8:04 AM > >To: intel-gfx@lists.freedesktop.org > >Cc: Srivatsa, Anusha ; Mcgee, Jeff > >;

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Advertise ppgtt support type in platform definition

== Series Details == Series: series starting with [1/2] drm/i915: Advertise ppgtt support type in platform definition URL : https://patchwork.freedesktop.org/series/16403/ State : warning == Summary == Series 16403v1 Series without cover letter

Re: [Intel-gfx] [lkp] [PATCH] drm/i915: Fix intel_psr_init() kerneldoc

On 11/30, Ander Conselvan De Oliveira wrote: >On Wed, 2016-11-30 at 09:29 +0800, kbuild test robot wrote: >> Hi Ander, >> >> [auto build test WARNING on drm-intel/for-linux-next] >> [also build test WARNING on v4.9-rc7 next-20161129] >> [if your patch is applied to the wrong git tree, please drop

[Intel-gfx] [PATCH 2/2] drm/i915: Keep has_* in alphabetical order

As it already says in the comment block... Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 88e70fe..13835b9

[Intel-gfx] [PATCH 1/2] drm/i915: Advertise ppgtt support type in platform definition

Instead of being hidden in sanitize_enable_ppgtt. It also seems to be the place to do so nowadays. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ drivers/gpu/drm/i915/i915_pci.c | 11

Re: [Intel-gfx] [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

Thank you! On Tue, 6 Dec 2016 at 01:47 Michel Dänzer wrote: > On 06/12/16 10:42 AM, Mike Lothian wrote: > > Hi > > > > This patch (in drm-next and drm-intel-nightly) stops my system from > > booting, I don't see any errors, just a black screen and a reboot after > > the

Re: [Intel-gfx] [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

On 06/12/16 10:42 AM, Mike Lothian wrote: > Hi > > This patch (in drm-next and drm-intel-nightly) stops my system from > booting, I don't see any errors, just a black screen and a reboot after > the kernel has been selected > > I have confirmed that reverting this patch gets those two branches

Re: [Intel-gfx] [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

Hi This patch (in drm-next and drm-intel-nightly) stops my system from booting, I don't see any errors, just a black screen and a reboot after the kernel has been selected I have confirmed that reverting this patch gets those two branches working again Sorry to be the bearer of bad news - I'm

Re: [Intel-gfx] [PATCH] drm/i915: Remove instructions to file a bug report.

On Sat, Dec 3, 2016 at 1:52 AM, Jani Nikula wrote: > On Sat, 03 Dec 2016, Matt Turner wrote: >> From these instructions, users assume that /sys/class/drm/card0/error >> contains all the information a developer needs to diagnose and fix a GPU >>

[Intel-gfx] ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent

== Series Details == Series: Link Training failure handling by sending Hotplug Uevent URL : https://patchwork.freedesktop.org/series/16399/ State : failure == Summary == Series 16399v1 Link Training failure handling by sending Hotplug Uevent

Re: [Intel-gfx] [PATCH] drm/i915: Copy user requested buffers into the error state

On Sat, Dec 3, 2016 at 7:46 AM, Chris Wilson wrote: > Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may > use to indicate that it wants the contents of this buffer preserved in > the error state (/sys/class/drm/cardN/error) following a GPU hang >

[Intel-gfx] [PATCH 3/4] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure and limits the max link_rate and lane_count values to these

[Intel-gfx] [PATCH 4/4] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[Intel-gfx] [PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

Sink's capabilities are advertised through DPCD registers and get updated only on hotplug. So they should be computed only once in the long pulse handler and saved off in intel_dp structure for the use later. For this reason two new fields max_sink_lane_count and max_sink_link_bw are added to

[Intel-gfx] [PATCH 1/4] drm: Add a new connector atomic property for link status

At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the

[Intel-gfx] [PATCH 0/4] Link Training failure handling by sending Hotplug Uevent

This patch series is a final revision of previous patch series for handling link training failure. This has been polished in terms of the kernel documentation based on review feedback. One more patch is added to move sink's max link rate and lane count to intel_dp and compute it at hotplug and

Re: [Intel-gfx] [PATCH] drm/i915/guc: Drop comment on fwif autogeneration

>-Original Message- >From: Hiler, Arkadiusz >Sent: Monday, December 5, 2016 8:04 AM >To: intel-gfx@lists.freedesktop.org >Cc: Srivatsa, Anusha ; Mcgee, Jeff >; Kamble, Sagar A >Subject: [PATCH] drm/i915/guc: Drop

Re: [Intel-gfx] [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

On Mon, Dec 5, 2016 at 2:47 PM, David Woodhouse wrote: > On Mon, 2016-12-05 at 14:18 -0800, Kees Cook wrote: >> Hm, I have no idea. :) What would I look for in the BIOS? > > For a start, what is the actual failure mode? Based on initial testing (not that I've spent tons of

Re: [Intel-gfx] [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

On Mon, 2016-12-05 at 14:18 -0800, Kees Cook wrote: > Hm, I have no idea. :) What would I look for in the BIOS? For a start, what is the actual failure mode? > I figured since g4 was busted, surely q35 was too, since it's even > older... Oh no, they all have different failures. Intel never

Re: [Intel-gfx] [PATCH] drm/dp/mst: fix kernel oops when turning off secondary monitor

On Mon, Dec 05, 2016 at 09:39:49PM +, Pandiyan, Dhinakaran wrote: > On Mon, 2016-12-05 at 08:02 +, Chris Wilson wrote: > > On Sun, Dec 04, 2016 at 07:31:18PM -0600, Pierre-Louis Bossart wrote: > > > 100% reproducible issue found on SKL SkullCanyon NUC with two external > > > DP

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp/mst: fix kernel oops when turning off secondary monitor (rev2)

== Series Details == Series: drm/dp/mst: fix kernel oops when turning off secondary monitor (rev2) URL : https://patchwork.freedesktop.org/series/16337/ State : failure == Summary == Series 16337v2 drm/dp/mst: fix kernel oops when turning off secondary monitor

Re: [Intel-gfx] [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

On Mon, Dec 5, 2016 at 2:07 PM, David Woodhouse wrote: > On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote: >> This blacklists the Q35 integrated graphics so IOMMU can be otherwise >> enabled. Without this, a Q35 system can only enable IOMMU when booting >> with

Re: [Intel-gfx] [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote: > This blacklists the Q35 integrated graphics so IOMMU can be otherwise > enabled. Without this, a Q35 system can only enable IOMMU when booting > with "intel_iommu=on,igfx_off" but not "intel_iommu=on". Hm, is this definitely the same bug? Or

Re: [Intel-gfx] [PATCH] drm/dp/mst: fix kernel oops when turning off secondary monitor

On 12/5/16 3:39 PM, Pandiyan, Dhinakaran wrote: On Mon, 2016-12-05 at 08:02 +, Chris Wilson wrote: On Sun, Dec 04, 2016 at 07:31:18PM -0600, Pierre-Louis Bossart wrote: 100% reproducible issue found on SKL SkullCanyon NUC with two external DP daisy-chained monitors in DP/MST mode. When

[Intel-gfx] [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

This blacklists the Q35 integrated graphics so IOMMU can be otherwise enabled. Without this, a Q35 system can only enable IOMMU when booting with "intel_iommu=on,igfx_off" but not "intel_iommu=on". 00:02.0 0300: 8086:29b2 (rev 02) (prog-if 00 [VGA controller]) Subsystem: 8086:4f4a

[Intel-gfx] [PATCH v2] drm/dp/mst: fix kernel oops when turning off secondary monitor

100% reproducible issue found on SKL SkullCanyon NUC with two external DP daisy-chained monitors in DP/MST mode. When turning off or changing the input of the second monitor the machine stops with a kernel oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly. This issue is traced

Re: [Intel-gfx] [PATCH] drm/dp/mst: fix kernel oops when turning off secondary monitor

On Mon, 2016-12-05 at 08:02 +, Chris Wilson wrote: > On Sun, Dec 04, 2016 at 07:31:18PM -0600, Pierre-Louis Bossart wrote: > > 100% reproducible issue found on SKL SkullCanyon NUC with two external > > DP daisy-chained monitors in DP/MST mode. When turning off or changing > > the input of the

Re: [Intel-gfx] [PATCH] drm/dp/mst: fix kernel oops when turning off secondary monitor

On Sun, 2016-12-04 at 19:31 -0600, Pierre-Louis Bossart wrote: > 100% reproducible issue found on SKL SkullCanyon NUC with two external > DP daisy-chained monitors in DP/MST mode. When turning off or changing > the input of the second monitor the machine stops with a kernel > oops. This issue

Re: [Intel-gfx] [PATCH] drm/i915/guc: Drop comment on fwif autogeneration

Reviewed-by: Jeff McGee On Mon, Dec 05, 2016 at 05:04:29PM +0100, Arkadiusz Hiler wrote: > The firmware interface file was initially partially autogenerated, but > this is no longer the case. > > It was never updated automatically, and a lot manual changes were >

Re: [Intel-gfx] [PATCH] drm/i915: Shrink pipe config checker

On Mon, Dec 05, 2016 at 12:10:41PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Replace INTEL_ERR_OR_DBG_KMS macro with an intel_err_or_dbg_kms > function to shrink the code and rodata strings. > >textdata bss dec hex filename > 1271480

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

>-Original Message- >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] >Sent: Thursday, December 1, 2016 5:11 AM >To: Srivatsa, Anusha ; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading

Re: [Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status

On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote: > > At the time userspace does setcrtc, we've already promised the mode > > would work. The promise is based on the theoretical capabilities of > > the link, but it's

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: add bxt dsi gpio element support (rev4)

== Series Details == Series: drm/i915/bxt: add bxt dsi gpio element support (rev4) URL : https://patchwork.freedesktop.org/series/15338/ State : warning == Summary == Series 15338v4 drm/i915/bxt: add bxt dsi gpio element support

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

Hi, On 05-12-16 19:52, Ville Syrjälä wrote: On Fri, Dec 02, 2016 at 03:29:04PM +0100, Hans de Goede wrote: On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification

== Series Details == Series: series starting with [v6,1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification URL : https://patchwork.freedesktop.org/series/16375/ State : success == Summary == Series 16375v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/6] drm/i915: Mark all non-vma being inserted into the address spaces

== Series Details == Series: series starting with [CI,1/6] drm/i915: Mark all non-vma being inserted into the address spaces URL : https://patchwork.freedesktop.org/series/16367/ State : success == Summary == Series 16367v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: Drop comment on fwif autogeneration

== Series Details == Series: drm/i915/guc: Drop comment on fwif autogeneration URL : https://patchwork.freedesktop.org/series/16373/ State : warning == Summary == Series 16373v1 drm/i915/guc: Drop comment on fwif autogeneration

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Mark the atomic commit_ready fence as freed (rev2)

== Series Details == Series: drm/i915: Mark the atomic commit_ready fence as freed (rev2) URL : https://patchwork.freedesktop.org/series/16352/ State : warning == Summary == Series 16352v2 drm/i915: Mark the atomic commit_ready fence as freed

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Respect ring_mask when initializing forcewake domains

== Series Details == Series: drm/i915: Respect ring_mask when initializing forcewake domains URL : https://patchwork.freedesktop.org/series/16362/ State : success == Summary == Series 16362v1 drm/i915: Respect ring_mask when initializing forcewake domains

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Shrink pipe config checker

== Series Details == Series: drm/i915: Shrink pipe config checker URL : https://patchwork.freedesktop.org/series/16359/ State : success == Summary == Series 16359v1 drm/i915: Shrink pipe config checker https://patchwork.freedesktop.org/api/1.0/series/16359/revisions/1/mbox/ Test gem_busy:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Enable dynamic debug for DRM_[DEV]_DEBUG* (rev2)

== Series Details == Series: drm: Enable dynamic debug for DRM_[DEV]_DEBUG* (rev2) URL : https://patchwork.freedesktop.org/series/16235/ State : success == Summary == Series 16235v2 drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

On Fri, Dec 02, 2016 at 03:29:04PM +0100, Hans de Goede wrote: > On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading > i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. > Once the i915 driver has successfully loaded, the panel can be disabled / >

Re: [Intel-gfx] [PATCH] drm/i915: Mark the atomic commit_ready fence as freed

Hi Chris, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20161205] [cannot apply to v4.9-rc8] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm

Re: [Intel-gfx] [PATCH] drm: parse hf-vsdb

On Tue, Nov 29, 2016 at 08:24:39PM +0530, Shashank Sharma wrote: > HDMI 2.0 / CEA-861-F specs define a new CEA extension data block, > called hdmi-forum vendor specific data block (HF-VSDB). This block > contains information about sink's support for HDMI 2.0 compliant > features. These features

Re: [Intel-gfx] [RFC] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

On Mon, Dec 05, 2016 at 11:24:44AM +, Robert Bragg wrote: > Forgot to send to dri-devel when I first sent this out... > > The few times I've looked at using DRM_DEBUG messages, I haven't found > them very helpful considering how noisy some of the categories are. More > than once now I've

[Intel-gfx] [PATCH v6 2/2] drm/i915/gen9: Fix PCODE polling during SAGV disabling

According to the previous patch, it's possible atm that we call intel_do_sagv_disable() only once during the 1ms period and time out if that call fails. As opposed to this the spec says that we need to keep retrying this request for a 1ms duration, so let's do this similarly to the CDCLK change

[Intel-gfx] [PATCH v6 1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification

commit 848496e5902833600f7992f4faa82dc1546051ba Author: Ville Syrjälä Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at

[Intel-gfx] [PATCH] drm/i915/guc: Drop comment on fwif autogeneration

The firmware interface file was initially partially autogenerated, but this is no longer the case. It was never updated automatically, and a lot manual changes were introduced since. From now on any changes to the firmware interface will be managed by hand, which gives us flexibility when it

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

On Tue, Nov 29, 2016 at 10:24:16PM +0200, Ville Syrjälä wrote: > On Tue, Nov 15, 2016 at 12:59:06PM -0800, Dhinakaran Pandiyan wrote: > > Not validating the mode rate against max. link rate results in not pruning > > invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not > > support

Re: [Intel-gfx] [PATCH 00/15] drm/i915: VLV/CHV atomic wm prep work

On Mon, Nov 28, 2016 at 07:37:02PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > A decent pile of prep work split off from my VLV/CHV atomic watermark > work. Mostly VLV/CHV specific stuff, but there are a few small things > in there that

[Intel-gfx] [CI 6/6] drm/i915/execlists: Use list_safe_reset_next() instead of opencoding

list.h provides a macro for updating the next element in a safe list-iter, so let's use it so that it is hopefully clearer to the reader about the unusual behaviour, and also easier to grep. Signed-off-by: Chris Wilson Reviewed-by: Jani Nikula

[Intel-gfx] [CI 2/6] drm/i915: Fix i915_gem_evict_for_vma (soft-pinning)

Soft-pinning depends upon being able to check for availabilty of an interval and evict overlapping object from a drm_mm range manager very quickly. Currently it uses a linear list, and so performance is dire and not suitable as a general replacement. Worse, the current code will oops if it tries

[Intel-gfx] [CI 4/6] drm/i915: Implement local atomic_state_free callback

As we use debugobjects to track the lifetime of fences within our atomic state, we ideally want to mark those objects as freed along with their containers. This merits us hookin into config->funcs->atomic_state_free for this purpose. This allows us to enable debugobjects for sw-fences without

[Intel-gfx] [CI 5/6] drm/i915: Enable swfence debugobject support for i915.ko

Only once the debugobject symbols are exported can we enable support for debugging swfences when i915 is built as a module. Requires commit 2617fdca3f68 ("lib/debugobjects: export for use in modules") Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [CI 3/6] drm/i915: Tidy i915_gem_valid_gtt_space()

We can replace a couple of tests with an assertion that the passed in node is already allocated (as matches the existing call convention) and by a small bit of refactoring we can bring the line lengths to under 80cols. Signed-off-by: Chris Wilson Reviewed-by: Joonas

[Intel-gfx] [CI 1/6] drm/i915: Mark all non-vma being inserted into the address spaces

We need to distinguish between full i915_vma structs and simple drm_mm_nodes when considering eviction (i.e. we must be careful not to treat a mere drm_mm_node as a much larger i915_vma causing memory corruption, if we are lucky). To do this, color these not-a-vma with -1 (I915_COLOR_UNEVICTABLE).

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/perf: More documentation hooked to i915.rst (rev2)

On Mon, Dec 05, 2016 at 01:55:02PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/perf: More documentation hooked to i915.rst (rev2) > URL : https://patchwork.freedesktop.org/series/16114/ > State : failure > > == Summary == > > Series 16114v2 drm/i915/perf: More

Re: [Intel-gfx] [PATCH] drm/i915: Implement local atomic_state_free callback

On 05/12/2016 14:09, Chris Wilson wrote: As we use debugobjects to track the lifetime of fences within our atomic state, we ideally want to mark those objects as freed along with their containers. This merits us hookin into config->funcs->atomic_state_free for this purpose. Signed-off-by:

[Intel-gfx] [PATCH v2 11/15] drm/i915: Protect DSPARB registers with a spinlock

From: Ville Syrjälä Each DSPARB register can house bits for two separate pipes, hence we must protect the registers during reprogramming so that parallel FIFO reconfigurations happening simultaneosly on multiple pipes won't corrupt each others values. We'll use a

[Intel-gfx] [PATCH] drm/i915: Implement local atomic_state_free callback

As we use debugobjects to track the lifetime of fences within our atomic state, we ideally want to mark those objects as freed along with their containers. This merits us hookin into config->funcs->atomic_state_free for this purpose. Signed-off-by: Chris Wilson ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/perf: More documentation hooked to i915.rst (rev2)

== Series Details == Series: drm/i915/perf: More documentation hooked to i915.rst (rev2) URL : https://patchwork.freedesktop.org/series/16114/ State : failure == Summary == Series 16114v2 drm/i915/perf: More documentation hooked to i915.rst

Re: [Intel-gfx] [PATCH i-g-t v9 00/21] Implement sw_sync test

This series has my Reviewed-by tag with the small issues I pointed out addressed. But I think it would be very good if you could go through all the igt_assert* calls and make sure that no information is being lost that could aid in triaging and debugging. The messages you chose for igt_assert_f

Re: [Intel-gfx] [PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight

Hi, On 05-12-16 11:59, Thierry Reding wrote: On Mon, Dec 05, 2016 at 09:18:03AM +0100, Hans de Goede wrote: Hi, On 05-12-16 08:46, Thierry Reding wrote: On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote: The primary consumer of the lpss pwm is the i915 kms driver, but currently

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/6] drm/i915: Mark all non-vma being inserted into the address spaces

== Series Details == Series: series starting with [CI,1/6] drm/i915: Mark all non-vma being inserted into the address spaces URL : https://patchwork.freedesktop.org/series/16353/ State : success == Summary == Series 16353v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915: Respect ring_mask when initializing forcewake domains

From: Elaine Wang Some platforms don't have render or blitter. So no need to call render domain or blitter domain forcewake init function. Cc: Joonas Lahtinen Signed-off-by: Elaine Wang ---

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Introduce drmfs pseudo filesystem for drm subsystem (rev3)

> == Series Details == > > Series: Introduce drmfs pseudo filesystem for drm subsystem (rev3) > URL : https://patchwork.freedesktop.org/series/16203/ > State : warning > > == Summary == > > Series 16203v3 Introduce drmfs pseudo filesystem for drm subsystem >

Re: [Intel-gfx] [PATCH i-g-t v9 09/21] tests/sw_sync: Add subtest test_sync_multi_consumer

On 22 November 2016 at 14:28, wrote: > From: Robert Foss > > This subtest verifies the access ordering of multiple consumer threads. > > Signed-off-by: Robert Foss > Reviewed-by: Eric Engestrom

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark the atomic commit_ready fence as freed

== Series Details == Series: drm/i915: Mark the atomic commit_ready fence as freed URL : https://patchwork.freedesktop.org/series/16352/ State : success == Summary == Series 16352v1 drm/i915: Mark the atomic commit_ready fence as freed

Re: [Intel-gfx] [PATCH i-g-t v9 01/21] lib/sw_sync: Add helper functions for managing synchronization primitives

Hi Robert, looks pretty good to me, have just found a few nits. With those addressed: Reviewed-by: Tomeu Vizoso Regards, Tomeu On 22 November 2016 at 14:28, wrote: > From: Robert Foss > > Base functions to

Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

On 5 December 2016 at 11:20, Robert Bragg wrote: > This adds a 'Perf' section to i915.rst with the following sub sections: > - Overview > - Comparison with Core Perf > - i915 Driver Entry Points > - i915 Perf Stream > - i915 Perf Observation Architecture Stream > - All i915

[Intel-gfx] ✗ Fi.CI.BAT: warning for Introduce drmfs pseudo filesystem for drm subsystem (rev3)

== Series Details == Series: Introduce drmfs pseudo filesystem for drm subsystem (rev3) URL : https://patchwork.freedesktop.org/series/16203/ State : warning == Summary == Series 16203v3 Introduce drmfs pseudo filesystem for drm subsystem

[Intel-gfx] [PATCH] drm/i915: Shrink pipe config checker

From: Tvrtko Ursulin Replace INTEL_ERR_OR_DBG_KMS macro with an intel_err_or_dbg_kms function to shrink the code and rodata strings. textdata bss dec hex filename 1271480 418312016 1315327 1411ff i915.ko.0 1265160 418312016 1309007

[Intel-gfx] [RFC] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

Forgot to send to dri-devel when I first sent this out... The few times I've looked at using DRM_DEBUG messages, I haven't found them very helpful considering how noisy some of the categories are. More than once now I've preferred to go in and modify individual files to affect what messages I see

[Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

This adds a 'Perf' section to i915.rst with the following sub sections: - Overview - Comparison with Core Perf - i915 Driver Entry Points - i915 Perf Stream - i915 Perf Observation Architecture Stream - All i915 Perf Internals v2: section headers in i915.rst (Daniel Vetter) missing symbol

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add I2C and DP-AUX char devices to debug kconfig

On pe, 2016-12-02 at 18:23 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add I2C and DP-AUX char devices to debug kconfig > URL   : https://patchwork.freedesktop.org/series/16295/ > State : success > > == Summary == > > Series 16295v1 drm/i915: Add I2C and DP-AUX char

[Intel-gfx] [CI 4/6] drm/i915: Mark the atomic commit_ready fence as freed

Using debugobjects allows us to detect if a freed fence is reused, or if an active fence is freed. However, this requires us to forewarn the debugobject when it is actually freed. Ideally this would hook into that atomic state->destroy callback so that we would catch the use of a destroyed fence

[Intel-gfx] [CI 1/6] drm/i915: Mark all non-vma being inserted into the address spaces

We need to distinguish between full i915_vma structs and simple drm_mm_nodes when considering eviction (i.e. we must be careful not to treat a mere drm_mm_node as a much larger i915_vma causing memory corruption, if we are lucky). To do this, color these not-a-vma with -1 (I915_COLOR_UNEVICTABLE).

[Intel-gfx] [CI 5/6] drm/i915: Enable swfence debugobject support for i915.ko

Only once the debugobject symbols are exported can we enable support for debugging swfences when i915 is built as a module. Requires commit 2617fdca3f68 ("lib/debugobjects: export for use in modules") Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [CI 3/6] drm/i915: Tidy i915_gem_valid_gtt_space()

We can replace a couple of tests with an assertion that the passed in node is already allocated (as matches the existing call convention) and by a small bit of refactoring we can bring the line lengths to under 80cols. Signed-off-by: Chris Wilson Reviewed-by: Joonas

[Intel-gfx] [CI 6/6] drm/i915/execlists: Use list_safe_reset_next() instead of opencoding

list.h provides a macro for updating the next element in a safe list-iter, so let's use it so that it is hopefully clearer to the reader about the unusual behaviour, and also easier to grep. Signed-off-by: Chris Wilson Reviewed-by: Jani Nikula

[Intel-gfx] [PATCH] drm/i915: Mark the atomic commit_ready fence as freed

Using debugobjects allows us to detect if a freed fence is reused, or if an active fence is freed. However, this requires us to forewarn the debugobject when it is actually freed. Ideally this would hook into that atomic state->destroy callback so that we would catch the use of a destroyed fence

[Intel-gfx] [CI 2/6] drm/i915: Fix i915_gem_evict_for_vma (soft-pinning)

Soft-pinning depends upon being able to check for availabilty of an interval and evict overlapping object from a drm_mm range manager very quickly. Currently it uses a linear list, and so performance is dire and not suitable as a general replacement. Worse, the current code will oops if it tries

Re: [Intel-gfx] [PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight

On Mon, Dec 05, 2016 at 09:18:03AM +0100, Hans de Goede wrote: > Hi, > > On 05-12-16 08:46, Thierry Reding wrote: > > On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote: > > > The primary consumer of the lpss pwm is the i915 kms driver, but > > > currently that driver cannot get the

[Intel-gfx] [RFC 1/4] drm: Introduce drmfs pseudo filesystem interfaces

From: Sourab Gupta The patch introduces a new pseudo filesystem type, named 'drmfs' which is intended to house the files for the data generated by drm subsystem that cannot be accommodated by any of the existing filesystems. The filesystem is modelled on the lines of

[Intel-gfx] [RFC 2/4] drm: Register drmfs filesystem from drm init

From: Sourab Gupta The drmfs filesystem will not be registered standalone during kernel init time, instead it is intended to be initialized/registered during drm initialization. Signed-off-by: Sourab Gupta Signed-off-by: Swati Dhingra

[Intel-gfx] [RFC 4/4] drm/i915: Creating guc log file in drmfs instead of debugfs

From: Sourab Gupta In the current scenario, the relay API fit well only with debugfs, due to availability of parent dentry. Any other existing filesystem was not feasible for holding guc logs, due to incompatibility with relay. But this makes the guc_log file

[Intel-gfx] [RFC 3/4] drm: Create driver specific root directory inside drmfs

From: Sourab Gupta A driver specific directory is created inside drmfs root, and dentry of this directory is saved for subsequent use by the driver (e.g. i915). The driver can then create files/directories inside this root directory directly. In case of i915 driver, the

[Intel-gfx] [RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

From: Swati Dhingra Currently, we don't have a stable ABI which can be used for the purpose of providing output debug/loggging/crc and other such data from DRM. The ABI in current use (filesystems, ioctls, et al.) have their own constraints and are intended to output a

Re: [Intel-gfx] [PATCH] drm/i915/guc: Do not bypass forcewakes in i915_guc_submit

On Mon, Dec 05, 2016 at 03:47:24PM +0530, Kamble, Sagar A wrote: > > > On 11/17/2016 3:06 PM, Tvrtko Ursulin wrote: > > > >On 17/11/2016 09:28, Chris Wilson wrote: > >>On Thu, Nov 17, 2016 at 09:17:35AM +, Tvrtko Ursulin wrote: > >>>From: Tvrtko Ursulin > >>> >

[Intel-gfx] [PATCH xf86-video-intel] Add Geminialke PCI IDs

Same ids from kernel's commit 8363e3c3947d0e22955f94a6a87e4f17ce5087b4 Author: Ander Conselvan de Oliveira Date: Thu Nov 10 17:23:08 2016 +0200 drm/i915/glk: Add Geminilake PCI IDs Signed-off-by: Ander Conselvan de Oliveira

Re: [Intel-gfx] [PATCH] drm/i915/guc: Do not bypass forcewakes in i915_guc_submit

On 11/17/2016 3:06 PM, Tvrtko Ursulin wrote: On 17/11/2016 09:28, Chris Wilson wrote: On Thu, Nov 17, 2016 at 09:17:35AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Commit ed4596ea992d ("drm/i915/guc: WA to address the Ringbuffer coherency issue"), based on

[Intel-gfx] [PATCH i-g-t v4] lib/debugfs: Support new generic ABI for CRC capture

The kernel has now a new debugfs ABI that can also allow capturing frame CRCs for drivers other than i915. Add alternative codepaths so the new ABI is used if the kernel is recent enough, and fall back to the legacy ABI if not. Signed-off-by: Tomeu Vizoso --- Hi,

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use list_safe_reset_next() instead of opencoding

On Sat, 03 Dec 2016, Chris Wilson wrote: > list.h provides a macro for updating the next element in a safe > list-iter, so let's use it so that it is hopefully clearer to the reader > about the unusual behaviour, and also easier to grep. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] Updated drm-intel-testing

> Subject: Re: [Intel-gfx] Updated drm-intel-testing > > On Mon, Dec 05, 2016 at 09:40:25AM +0100, Daniel Vetter wrote: > > Hi all, > > > > New -testing cycle with cool stuff: > > First round of stuff for 4.10! > > ofc this should have been 4.11 ... > -Daniel Thanks Daniel! with Julian we are

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp/mst: fix kernel oops when turning off secondary monitor

== Series Details == Series: drm/dp/mst: fix kernel oops when turning off secondary monitor URL : https://patchwork.freedesktop.org/series/16337/ State : success == Summary == Series 16337v1 drm/dp/mst: fix kernel oops when turning off secondary monitor

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: First round of stuff for 4.10! - refactor hangcheck/ban/reset stats code in prep for TDR (Mika) - much more fancy perf monitoring support (Robert Bragg) - lspcon fixes (Imre) - rework plane ids to unconfuse the code (Ville) - fix up cdclck/atomic state

  1   2   >