[Intel-gfx] [PATCH] drm: Print device information again in debugfs

I was a bit over-eager in my cleanup in commit 95c081c17f284de50eaca60d4d55643a64d39019 Author: Daniel Vetter Date: Tue Jun 21 10:54:12 2016 +0200 drm: Move master pointer from drm_minor to drm_device Noticed by Chris Wilson. Fixes: 95c081c17f28 ("drm: Move

Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs

On Thu, Oct 13, 2016 at 10:13 AM, Daniel Vetter wrote: > I was a bit over-eager in my cleanup in > > commit 95c081c17f284de50eaca60d4d55643a64d39019 > Author: Daniel Vetter > Date: Tue Jun 21 10:54:12 2016 +0200 > > drm: Move master pointer

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > We can remove the false coupling between RPM and struct mutex by the > observation that we can use the RPM wakeref as the barrier around user > mmap access. That is as we tear down the user's PTE atomically from > within rpm suspend

Re: [Intel-gfx] [maintainer-tools PATCH 6/6] dim: add command to check for dim updates

On Tue, Oct 11, 2016 at 04:07:30PM +0300, Jani Nikula wrote: > On Tue, 11 Oct 2016, Daniel Vetter wrote: > > On Tue, Oct 11, 2016 at 11:47:32AM +0300, Jani Nikula wrote: > >> Add a command to check if the user is running an up-to-date version of > >> dim. > >> > >>

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

Reviewed-by: Jeff McGee On Mon, Oct 03, 2016 at 11:42:55AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > Rename some of the GuC fw loading code to make them more general. We > will utilise them for HuC loading as well. >

Re: [Intel-gfx] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api

On Thu, Oct 13, 2016 at 10:49:39AM +0100, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 12:31:13PM +0300, Abdiel Janulgue wrote: > > > > > > On 10/12/2016 03:07 PM, Chris Wilson wrote: > > > On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote: > > >> Signed-off-by: Abdiel Janulgue

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

On Thu, Oct 13, 2016 at 04:15:23PM +0100, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote: > > On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > > b/drivers/gpu/drm/i915/i915_gem.c > > > index

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use fence_write() from rpm resume

On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device *dev) > > * Commit delayed tiling changes if we have an object still > >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove superfluous locking around userfault_list

On Tue, Oct 11, 2016 at 03:37:59PM +0100, Chris Wilson wrote: > Now that we have reduced the access to the list to either (a) under the > struct_mutex whilst holding the RPM wakeref (so that concurrent writers to > the list are serialised by struct_mutex) and (b) under the atomic > runtime suspend

Re: [Intel-gfx] [PATCH] drm/i915: Assert we hold the CRTC powerwell for generating vblank interrupts

On Thu, Oct 13, 2016 at 04:17:07PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 07:21:44AM +0200, Maarten Lankhorst wrote: > > I don't see a nice way to do this, it probably means we shouldn't do this > > at all.. > > Maybe have a function look at > >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

On 10/10/2016 6:03 PM, Patchwork wrote: == Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series 13435v3 drm/i915: Allocate intel_engine_cs

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use fence_write() from rpm resume

On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > During rpm resume we restore the fences, but we do not have the > protection of struct_mutex. This rules out updating the activity > tracking on the fences, and requires us to rely on the rpm as the > serialisation barrier instead. >

Re: [Intel-gfx] [PATCH v4 8/8] drm/i915/bxt: Enable IPC support

On Thu, Oct 13, 2016 at 06:31:37PM +0530, Mahesh Kumar wrote: > Hi, > > > On Thursday 13 October 2016 04:49 PM, Maarten Lankhorst wrote: > > Op 13-10-16 om 12:58 schreef Kumar, Mahesh: > > > From: Mahesh Kumar > > > > > > This patch adds IPC support for platforms. This

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote: > On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 91910ffe0964..587a91af5a3f 100644 > > ---

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Save megabytes of wasted sg entries

On Thu, Oct 13, 2016 at 11:24:46AM +, Saarinen, Jani wrote: > > == Series Details == > > > > Series: Save megabytes of wasted sg entries > > URL : https://patchwork.freedesktop.org/series/13706/ > > State : failure > > > > == Summary == > > > > Series 13706v1 Save megabytes of wasted sg

Re: [Intel-gfx] [PATCH v2] drm/i915: Allow compaction upto SWIOTLB max segment size

On Wed, Oct 12, 2016 at 10:51:57PM +0100, Chris Wilson wrote: > On Wed, Oct 12, 2016 at 05:19:14PM -0400, Konrad Rzeszutek Wilk wrote: > > On Mon, Oct 10, 2016 at 11:27:00PM +0100, Chris Wilson wrote: > > > commit 1625e7e549c5 ("drm/i915: make compact dma scatter lists creation > > > work with

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move user fault tracking to a separate list

On Tue, Oct 11, 2016 at 03:37:57PM +0100, Chris Wilson wrote: > We want to decouple RPM and struct_mutex, but currently RPM has to walk > the list of bound objects and remove userspace mmapping before we > suspend (otherwise userspace may continue to access the GTT whilst it is > powered down).

Re: [Intel-gfx] [PATCH] drm/i915: Skip unbinding large unmappable global buffers

On Thu, Oct 13, 2016 at 03:13:51PM +0100, Tvrtko Ursulin wrote: > > On 13/10/2016 13:59, Chris Wilson wrote: > >On Thu, Oct 13, 2016 at 12:29:44PM +0100, Tvrtko Ursulin wrote: > >>On 13/10/2016 09:55, Chris Wilson wrote: > >>>If the user requests a mappable binding to the global GTT, we will

Re: [Intel-gfx] [CI 3/6] drm/i915: Stop the machine whilst capturing the GPU crash dump

On Thu, Oct 13, 2016 at 04:57:39PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 10:05:19AM +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

Re: [Intel-gfx] [CI 4/6] drm/i915: Always use the GTT for error capture

On Thu, Oct 13, 2016 at 05:02:50PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 10:05:20AM +0100, Chris Wilson wrote: > > Since the GTT provides universal access to any GPU page, we can use it > > to reduce our plethora of read methods to just one. It also has the > > important

Re: [Intel-gfx] [CI 3/6] drm/i915: Stop the machine whilst capturing the GPU crash dump

On Wed, Oct 12, 2016 at 10:05:19AM +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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > HuC firmware css header has almost exactly same definition as GuC > firmware except for the sw_version. Also, add a new member fw_type > into intel_uc_fw to indicate what kind of

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Save megabytes of wasted sg entries

On 13/10/2016 16:33, Daniel Vetter wrote: On Thu, Oct 13, 2016 at 11:24:46AM +, Saarinen, Jani wrote: == Series Details == Series: Save megabytes of wasted sg entries URL : https://patchwork.freedesktop.org/series/13706/ State : failure == Summary == Series 13706v1 Save megabytes of

Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs

On Thu, Oct 13, 2016 at 04:13:44PM +0200, Daniel Vetter wrote: > I was a bit over-eager in my cleanup in > > commit 95c081c17f284de50eaca60d4d55643a64d39019 > Author: Daniel Vetter > Date: Tue Jun 21 10:54:12 2016 +0200 > > drm: Move master pointer from drm_minor

Re: [Intel-gfx] [CI 4/6] drm/i915: Always use the GTT for error capture

On Wed, Oct 12, 2016 at 10:05:20AM +0100, Chris Wilson wrote: > Since the GTT provides universal access to any GPU page, we can use it > to reduce our plethora of read methods to just one. It also has the > important characteristic of being exactly what the GPU sees - if there > are incoherency

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use fence_write() from rpm resume

On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote: > > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device *dev) > > >*

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use fence_write() from rpm resume

On Thu, Oct 13, 2016 at 05:28:13PM +0200, Daniel Vetter wrote: > On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote: > > On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote: > > > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > > > > @@ -379,10 +389,17 @@ void

Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatched INIT power domain disabling during suspend

On to, 2016-10-13 at 15:21 +0300, Jani Nikula wrote: > On Thu, 13 Oct 2016, Imre Deak wrote: > > Currently the display INIT power domain disabling/enabling happens in a > > mismatched way in the suspend/resume_early hooks respectively. This can > > leave display power wells

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check

Reviewed-by: Jeff McGee On Mon, Oct 03, 2016 at 11:42:58AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > Add debugfs entry for HuC loading status check. > > v2: rebase on-top of drm-intel-nightly. > v3: rebased again. > v7: rebased. >

Re: [Intel-gfx] [PATCH v2 2/4] drm: Add aspect ratio parsing in DRM layer

On Tue, Aug 09, 2016 at 08:25:48PM +0530, Shashank Sharma wrote: > Current DRM layer functions don't parse aspect ratio information > while converting a user mode->kernel mode or vice versa. This > causes modeset to pick mode with wrong aspect ratio, eventually > causing failures in HDMI

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

On 13/10/2016 17:10, Goel, Akash wrote: On 10/10/2016 6:03 PM, Patchwork wrote: == Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Respect alternate_aux_channel for all DDI ports

On Tue, Oct 11, 2016 at 08:52:45PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The VBT provides the platform a way to mix and match the DDI ports vs. > AUX channels. Currently we only trust the VBT for DDI E, which has no > corresponding

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

On Tue, Oct 11, 2016 at 08:52:47PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that we use the AUX and GMBUS assignment from VBT for all ports, > let's clean up the sanitization of the port information a bit. > Previosuly we only did

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4)

== Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series 13435v4 drm/i915: Allocate intel_engine_cs structure only for the enabled engines

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

[Adding Matt] On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: > Bisecting the offending commit between v4.8 and v4.8.1 would be a good > start. 0) Why use a personal notebook when one can just post any half baked idea to lkml? 1) I stumbled on 

[Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

According to BSpec, cdclk has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz) Having a lower cdclk triggers pipe underruns, which then lead to displays continuously cycling off and on. This is essential for DP MST audio as the link is trained at HBR2

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > is used for both cases. > > HuC loading needs to be before GuC loading. The WOPCM setting must > be done early

Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs

On 13 October 2016 at 15:13, Daniel Vetter wrote: > I was a bit over-eager in my cleanup in > > commit 95c081c17f284de50eaca60d4d55643a64d39019 > Author: Daniel Vetter > Date: Tue Jun 21 10:54:12 2016 +0200 > > drm: Move master pointer from

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

On Tue, Oct 11, 2016 at 08:52:46PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The VBT provides the platform a way to mix and match the DDI ports vs. > GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose > has no

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Print device information again in debugfs

== Series Details == Series: drm: Print device information again in debugfs URL : https://patchwork.freedesktop.org/series/13731/ State : warning == Summary == Series 13731v1 drm: Print device information again in debugfs

[Intel-gfx] [PATCH v11] drm/i915: Allocate intel_engine_cs structure only for the enabled engines

From: Akash Goel With the possibility of addition of many more number of rings in future, the drm_i915_private structure could bloat as an array, of type intel_engine_cs, is embedded inside it. struct intel_engine_cs engine[I915_NUM_ENGINES]; Though this is still

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

On Tue, Aug 09, 2016 at 08:25:47PM +0530, Shashank Sharma wrote: > This patch adds drm flag bits for aspect ratio information > > Currently drm flag bits don't have field for mode's picture > aspect ratio. This field will help the driver to pick mode with > right aspect ratio, and help in setting

Re: [Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios in DRM layer

On Tue, Aug 09, 2016 at 08:25:50PM +0530, Shashank Sharma wrote: > HDMI 2.0/CEA-861-F introduces two new aspect ratios: > - 64:27 > - 256:135 > > This patch: > - Adds new DRM flags for to represent these new aspect ratios. > - Adds new cases to handle these aspect ratios while converting > from

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

Em Qui, 2016-10-13 às 11:04 -0700, Dhinakaran Pandiyan escreveu: > According to BSpec, cdclk has to be not less than 432 MHz with DP > audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) This is just for pre-production hardware, and we don't implement workarounds for pre-prod. A quick

Re: [Intel-gfx] [RFC PATCH v2 4/8] drm/i915: Add support for enabling/disabling hdmi audio interrupts

+/* Added for HDMI Audio */ +int i915_enable_hdmi_audio_int(struct drm_i915_private *dev_priv) +{ + unsigned long irqflags; + u32 imr, int_bit; + int pipe = -1; + + spin_lock_irqsave(_priv->irq_lock, irqflags); + + imr = I915_READ(VLV_IMR); + + if

Re: [Intel-gfx] [PATCH v2 06/10] drm/i915/gen9: Add ddb changes to atomic debug output

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > Finally, add some debugging output for ddb changes in the atomic > debug > output. This makes it a lot easier to spot bugs from incorrect ddb > allocations. > > Signed-off-by: Lyude > Reviewed-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

On Thu, Oct 13, 2016 at 11:06:55AM -0700, Jim Bride wrote: > On Tue, Oct 11, 2016 at 08:52:46PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > The VBT provides the platform a way to mix and match the DDI ports vs. > > GMBUS pins.

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

> > == Series Details == > > > > Series: drm/i915: Allocate intel_engine_cs structure only for the enabled > engines (rev3) > > URL : https://patchwork.freedesktop.org/series/13435/ > > State : warning > > > > == Summary == > > > > Series 13435v3 drm/i915: Allocate intel_engine_cs structure only

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

Em Qui, 2016-10-13 às 17:04 -0300, Paulo Zanoni escreveu: > Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu: > > > > Op 08-10-16 om 02:11 schreef Lyude: > > > > > > > > > Now that we've make skl_wm_levels make a little more sense, we > > > can > > > remove all of the redundant wm

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote: > According to BSpec, cdclk has to be not less than 432 MHz with DP audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) > > Having a lower cdclk triggers pipe underruns, which then lead to displays > continuously

[Intel-gfx] [PATCH] drm/edid: Only print the bad edid when aborting

Currently, if drm.debug is enabled, we get a DRM_ERROR message on the intermediate edid reads. This causes transient failures in CI which flags up the sporadic EDID read failures, which are recovered by rereading the EDID automatically. This patch combines the reporting done by drm_do_get_edid()

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu: > Op 08-10-16 om 02:11 schreef Lyude: > > > > Now that we've make skl_wm_levels make a little more sense, we can > > remove all of the redundant wm information. Up until now we'd been > > storing two copies of all of the skl

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Fix whitespace issues

On Tue, Oct 11, 2016 at 08:52:48PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Fix the poorly indented port parameters to the aux ctl and data > reg functions. This was fallout from the s/i915_mmio_reg_t/i915_reg_t/ > that happened during

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

On Thu, Oct 13, 2016 at 06:47:24PM +, Saarinen, Jani wrote: > > > == Series Details == > > > > > > Series: drm/i915: Allocate intel_engine_cs structure only for the enabled > > engines (rev3) > > > URL : https://patchwork.freedesktop.org/series/13435/ > > > State : warning > > > > > > ==

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote: > According to BSpec, cdclk has to be not less than 432 MHz with DP audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) > > Having a lower cdclk triggers pipe underruns, which then lead to displays > continuously

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

== Series Details == Series: drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2 URL : https://patchwork.freedesktop.org/series/13745/ State : success == Summary == Series 13745v1 drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

Re: [Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver

Thanks Ville for the review. A lot of the comments are related to the initial VED code we took pretty much as is, no issues to clean-up further. BTW, it looks like Jerome's patches were stuck for 10+ days on the intel-gfx server for some reason so not everyone saw the initial post? @@

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Only print the bad edid when aborting

== Series Details == Series: drm/edid: Only print the bad edid when aborting URL : https://patchwork.freedesktop.org/series/13747/ State : warning == Summary == Series 13747v1 drm/edid: Only print the bad edid when aborting

Re: [Intel-gfx] [PATCH 07/10] drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > There's not much of a reason this should have the locations to read > out > the hardware state hardcoded, so allow the caller to specify the > location and add this function to intel_drv.h. As well, we're going > to > need this function to be

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Thu, Oct 13, 2016 at 10:42:42AM -0700, Jeff McGee wrote: > On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote: > > From: Peter Antoine > > > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > > is used for both cases. > > > > HuC

Re: [Intel-gfx] Problem with emgd on fedora 18

On Thu, Oct 13, 2016 at 03:28:05PM +0300, Jani Nikula wrote: > On Thu, 13 Oct 2016, Anteja Vuk Macek wrote: > > Hi, > > I work with Fedora 18 and I'm new in linux world. I have problem with emgd > > driver. I put emgd driver in kernel and build kernel. Moduled is build

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

Your is SAGV related, and when we don't make the SAGV happy people's machines usually hang. So I'm definitely for your patches getting merged first On Thu, 2016-10-13 at 17:07 -0300, Paulo Zanoni wrote: > Em Qui, 2016-10-13 às 17:04 -0300, Paulo Zanoni escreveu: > > > > Em Qui, 2016-10-13 às

Re: [Intel-gfx] [PATCH 5/8] drm/i915/huc: Support HuC authentication

On Mon, Oct 03, 2016 at 11:42:59AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of drm-intel-nightly. > changed name format and

Re: [Intel-gfx] [PATCH 7/8] drm/i915/get_params: Add GuC status to getparams

On Fri, Oct 07, 2016 at 09:11:03AM +0200, Daniel Vetter wrote: > On Wed, Oct 05, 2016 at 01:51:14PM -0700, Rodrigo Vivi wrote: > > > > > > Reviewed-by: Rodrigo Vivi > > This is new uabi. Where's the userspace? > > Checking this is part of the review. > -Daniel > I'm

Re: [Intel-gfx] [PATCH 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()

Em Qui, 2016-10-13 às 18:15 -0300, Paulo Zanoni escreveu: > Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > > > > Thanks to Paulo Zanoni for indirectly pointing this out. > > > > Looks like we never actually added any code for checking whether or > > not > > we actually wrote watermark

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

On Mon, Oct 03, 2016 at 11:43:00AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch adds the HuC Loading for the BXT. > Version 1.7 of the HuC firmware. > > v2: rebased. > v3: rebased. > changed file name to match the install package format. > v7:

Re: [Intel-gfx] [PATCH 08/10] drm/i915/gen9: Add skl_wm_level_equals()

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > Helper we're going to be using for implementing verification of the > wm > levels in skl_verify_wm_level(). > > Signed-off-by: Lyude Reviewed-by: Paulo Zanoni > Cc: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > Thanks to Paulo Zanoni for indirectly pointing this out. > > Looks like we never actually added any code for checking whether or > not > we actually wrote watermark levels properly. Let's fix that. Thanks for doing this! Reviewed-by: Paulo

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

On Mon, Oct 03, 2016 at 11:43:02AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch will allow for getparams to return the status of the HuC. > As the HuC has to be validated by the GuC this patch uses the validated > status to show when the HuC is

Re: [Intel-gfx] [PATCH 10/10] drm/i915/gen9: Don't wrap strings in verify_wm_state()

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: Bikesheding: it would be nice to write a commit message explaining why, even if the message just tells the user to read Documentation/CodingStyle. Reviewed-by: Paulo Zanoni > Signed-off-by: Lyude >

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

On Thu, Oct 13, 2016 at 08:45:45AM -0700, Jeff McGee wrote: > On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote: > > From: Peter Antoine > > > > HuC firmware css header has almost exactly same definition as GuC > > firmware except for the sw_version. Also,

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

Tested-by: Libin Yang Regards, Libin > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Dhinakaran Pandiyan > Sent: Friday, October 14, 2016 2:04 AM > To: intel-...@freedesktop.org > Cc: Nikula, Jani

[Intel-gfx] [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes

[Intel-gfx] [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

This patch removes the write parameter from access_process_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

[Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

This patch series adjusts functions in the get_user_pages* family such that desired FOLL_* flags are passed as an argument rather than implied by flags. The purpose of this change is to make the use of FOLL_FORCE explicit so it is easier to grep for and clearer to callers that this flag is being

[Intel-gfx] [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages_locked() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo

[Intel-gfx] [RFC 7/7] drm/i915: Trim sg table after creating it

From: Tvrtko Ursulin Since most of our callers do not know in advance how many entries in the sg table they will need, it is beneficial to trim the table after it has been created. Use the newly added sg_trim_table to do that when i915_sg_complete is called. Before we

[Intel-gfx] [RFC 6/7] lib/scatterlist: Add sg_trim_table

From: Tvrtko Ursulin *** BROKEN *** RFC only *** BROKEN *** In cases where it is hard to know to minimum numbers of ents table will need to hold at sg_alloc_time, and we end up with a table with unused sg entries at its end, this function will trim (free) the unused sg

[Intel-gfx] [RFC 0/7] Save megabytes of wasted sg entries

From: Tvrtko Ursulin We can decrease the i915 slab usage by 1-6 MiB* easily by doing more sg list coalescing and having the tables at the correct size at the same time. This series extracts the sg table building code into helper so that all places in i915 can benefit.

[Intel-gfx] [RFC 3/7] drm/i915: Use i915_sg_create for partial views

From: Tvrtko Ursulin Simplify the partial view creation loop by using the newly introduced helpers. It also allows the list to be coalesced when possbile. New i915_sg_add_dma helper was added to allow adding just the DMA address entries to the list. Signed-off-by:

Re: [Intel-gfx] [RFC 1/7] drm/i915: Extract sg creation into a helper

On Thu, Oct 13, 2016 at 10:03:58AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In order to reuse the same logic in several places in the driver, > extract the logic which adds pages to the sg list and does the > potential coalescing, into separate functions.

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Support for sustained capturing of GuC firmware logs (rev11)

On 12/10/2016 19:36, Saarinen, Jani wrote: == Series Details == Series: Support for sustained capturing of GuC firmware logs (rev11) URL : https://patchwork.freedesktop.org/series/7910/ State : warning == Summary == Series 7910v11 Support for sustained capturing of GuC firmware logs

[Intel-gfx] [PATCH 03/10] mm: replace get_user_pages_unlocked() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages_unlocked() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo

[Intel-gfx] [PATCH 07/10] mm: replace get_user_pages_remote() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages_remote() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo

[Intel-gfx] [PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()

This patch removes the write and force parameters from __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes ---

[Intel-gfx] [PATCH 05/10] mm: replace get_vaddr_frames() write/force parameters with gup_flags

This patch removes the write and force parameters from get_vaddr_frames() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes

[Intel-gfx] [PATCH 09/10] mm: replace access_remote_vm() write parameter with gup_flags

This patch removes the write parameter from access_remote_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

[Intel-gfx] [PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked()

This patch removes the write and force parameters from __get_user_pages_locked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes --- mm/gup.c |

[Intel-gfx] [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

This patch removes the write parameter from __access_remote_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

Re: [Intel-gfx] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api

On 10/12/2016 03:07 PM, Chris Wilson wrote: > On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote: >> Signed-off-by: Abdiel Janulgue >> --- >> tests/gem_wait.c | 77 >> +--- >> 1 file changed, 12

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Remove kms_psr_sink_crc@psr_basic from BAT

On Wed, Oct 12, 2016 at 2:13 PM, Petri Latvala wrote: > The test is producing a lot of CI noise. > > Signed-off-by: Petri Latvala > --- > > Will be pushed shortly. Visible in CI results tomorrow-ish. > > > tests/intel-ci/fast-feedback.testlist |

[Intel-gfx] [patch] drm/i915: fix a read size argument

We want to read 3 bytes here, but because the parenthesis are in the wrong place we instead read: sizeof(intel_dp->edp_dpcd) == sizeof(intel_dp->edp_dpcd) which is one byte. Fixes: fe5a66f91c88 ("drm/i915: Read PSR caps/intermediate freqs/etc. only once on eDP") Signed-off-by: Dan

Re: [Intel-gfx] [RFC 6/7] lib/scatterlist: Add sg_trim_table

On Thu, Oct 13, 2016 at 10:04:03AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > *** BROKEN *** RFC only *** BROKEN *** > > In cases where it is hard to know to minimum numbers of ents > table will need to hold at sg_alloc_time, and we end up with > a table

Re: [Intel-gfx] [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion

Op 12-10-16 om 19:15 schreef Lyude: > Accidentally sent original view twice and found one more issue after > looking at the rest of them, sorry about that! > > On Wed, 2016-10-12 at 13:04 -0400, Lyude wrote: >> Loving this patch so far! Would it be possible to get this split into >> two separate

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, Sumits undug himself from conference traveling, so here's one more pull request for 4.9, essentially just containing the reservation rcu fixes and polish from Chris. Btw plan is that between -rc1 and -rc2 we do a tree-wide s/fence/dma_fence/ since the current name is a bit too generic

Re: [Intel-gfx] [patch] drm/i915: fix a read size argument

On Thu, Oct 13, 2016 at 11:55:08AM +0300, Dan Carpenter wrote: > We want to read 3 bytes here, but because the parenthesis are in the > wrong place we instead read: > > sizeof(intel_dp->edp_dpcd) == sizeof(intel_dp->edp_dpcd) > > which is one byte. > > Fixes: fe5a66f91c88 ("drm/i915: Read

Re: [Intel-gfx] [patch] drm/i915: fix a read size argument

On Thu, Oct 13, 2016 at 11:55:08AM +0300, Dan Carpenter wrote: > We want to read 3 bytes here, but because the parenthesis are in the > wrong place we instead read: > > sizeof(intel_dp->edp_dpcd) == sizeof(intel_dp->edp_dpcd) > > which is one byte. > > Fixes: fe5a66f91c88 ("drm/i915: Read

Re: [Intel-gfx] [PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()

On 13/10/2016 02:20, Lorenzo Stoakes wrote: > This patch removes the write and force parameters from > __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers > as > use of this flag can result in surprising behaviour (and hence bugs) within > the > mm subsystem. > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode URL : https://patchwork.freedesktop.org/series/13663/ State : failure == Summary == Series 13663v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915: Skip unbinding large unmappable global buffers

If the user requests a mappable binding to the global GTT, we will first unbind an existing mapping if it doesn't match. We will unbind even if there is no possibility that the object can fit in the mappable aperture. This may lead to a ping-pong migration of the object, for example

  1   2   3   >