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

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: include/drm/drmP.h between commit: c4e68a583202 ("drm: Introduce DRM_DEV_* log messages") from the drm tree and commit: 30b0da8d556e ("drm: extra printk() wrapper macros") from the drm-intel tree. I fixed it up

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

== Series Details == Series: SKL/KBL watermark fixes URL : https://patchwork.freedesktop.org/series/12082/ State : warning == Summary == Series 12082v1 SKL/KBL watermark fixes http://patchwork.freedesktop.org/api/1.0/series/12082/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup

[Intel-gfx] ✗ Fi.CI.BAT: warning for Enable upfront link training on DDI platforms (rev8)

== Series Details == Series: Enable upfront link training on DDI platforms (rev8) URL : https://patchwork.freedesktop.org/series/10821/ State : warning == Summary == Series 10821v8 Enable upfront link training on DDI platforms

[Intel-gfx] [PATCH 4/8] drm/i915/gen9: fix the WaWmMemoryReadLatency implementation

Bspec says: "The mailbox response data may not account for memory read latency. If the mailbox response data for level 0 is 0us, add 2 microseconds to the result for each valid level." This means we should only do the +2 in case wm[0] == 0, not always. So split the sanitizing

[Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

According to BSpec, it's the "core CPUs" that need the code, which means SKL and KBL, but not BXT. I don't have a KBL to test this patch on it. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Intel-gfx] [PATCH 1/8] drm/i915: SAGV is not SKL-only, so rename a few things

The plan is to introduce intel_has_sagv() and then use it to discover which platforms actually support it. I thought about keeping the functions with their current skl names, but found two problems: (i) skl_has_sagv() would become a very confusing name, and (ii) intel_atomic_commit_tail() doesn't

[Intel-gfx] [PATCH 2/8] drm/i915: introduce intel_has_sagv()

And use it to move knowledge about the SAGV-supporting platforms from the callers to the SAGV code. We'll add more platforms to intel_has_sagv(), so IMHO it makes more sense to move all this to a single function instead of patching all the callers every time we add SAGV support to a new platform.

[Intel-gfx] [PATCH 5/8] drm/i915/gen9: minimum scanlines for Y tile is not always 4

During watermarks calculations, this value is used in 3 different places. Only one of them was not using a hardcoded 4. Move the code up so everybody can benefit from the actual value. This should only help on situations with Y tiling + 90/270 rotation + 1 or 2 bpp or NV12. Signed-off-by: Paulo

[Intel-gfx] [PATCH 7/8] drm/i915/gen9: fix the watermark res_blocks value

We forgot the "res_blocks += y_tile_minimum" that's described on step V of our documentation. Again, this should only affect the Y tiling cases. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_pm.c | 12 +++- 1 file changed, 7 insertions(+), 5

[Intel-gfx] [PATCH 6/8] drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations

The confusing thing is that plane_blocks_per_line is listed as part of the method 2 calculation but is also used for other things. We calculated it in two different places and different ways: one inside skl_wm_method2() and the other inside skl_compute_plane_wm(). The skl_wm_method2()

[Intel-gfx] [PATCH 0/8] SKL/KBL watermark fixes

Hi This series is the result of me comparing the code against BSpec. It doesn't solve any particular problem I was seeing, but there's enough changes that this code could potentially change the watermarks values for most machines. Maybe this will fix somebody's underrun? Even if it doesn't, we

[Intel-gfx] [PATCH 8/8] drm/i915/gen9: implement missing case for SKL watermarks calculation

This should affect linear and X tiled planes on really small htotal cases. It doesn't seem to be a very feasible case, but let's implement it since it's on the specification and it's better to have it and never need than not have it and realize we needed it. Signed-off-by: Paulo Zanoni

[Intel-gfx] [PATCH v2 14/14] drm/i915/dp/mst: Add support for upfront link training for DP MST

From: Jim Bride Add upfront link training to intel_dp_mst_mode_valid() so that we know topology constraints before we validate the legality of modes to be checked. Call the function that loops through the link rates and lane counts starting from highest supported link

[Intel-gfx] [PATCH v2 8/14] drm/i915/dp: Move max. vswing check to it's own function

From: Dhinakaran Pandiyan Wrap the max. vswing check in a separate function. This makes the clock recovery phase of DP link training cleaner v2: Fixed the Compiler warning (Mika Kahola) Signed-off-by: Dhinakaran Pandiyan

[Intel-gfx] [PATCH v12 13/14] drm/i915/dp: Enable Upfront link training for typeC DP support on HSW/BDW/SKL/BXT (DDI platforms)

From: Durgadoss R To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel

[Intel-gfx] [PATCH v2 9/14] drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2

From: Dhinakaran Pandiyan This function cleans up clock recovery loop in link training compliant tp Dp Spec 1.2. It tries the clock recovery 5 times for the same voltage or until max voltage swing is reached and removes the additional non compliant retries. This

[Intel-gfx] [PATCH v2 11/14] drm/i915: Fallback to lower link rate and lane count during link training

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 with Channel EQ. In case of Channel EQ failures, it should fallback to lower

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

On Wed, Aug 31, 2016 at 05:20:26PM -0700, 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 enabled

Re: [Intel-gfx] [PATCH 08/14] drm/i915/dp: Move max. vswing check to it's own function

On Tue, Sep 06, 2016 at 12:58:29PM +0300, Mika Kahola wrote: > On Fri, 2016-09-02 at 11:05 +0300, Mika Kahola wrote: > > +1 for this cleanup > > > > Reviewed-by: Mika Kahola > Received couple of compiler warnings to be cleaned up > >

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

On 06/09/16 12:21, Dave Gordon wrote: > On 04/09/16 19:58, Nicolas Iooss wrote: >> When building the kernel with clang and some warning flags, the compiler >> reports that the return value of dcs_get_backlight() may be >> uninitialized: >> >>

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

On Tue, Sep 06, 2016 at 06:39:12PM +, Srivatsa, Anusha wrote: > Sending to the list again since Ville's review comment didn't hit the > mailing list last time. > > Regards, > Anusha > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Monday,

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

Sending to the list again since Ville's review comment didn't hit the mailing list last time. Regards, Anusha -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Monday, September 5, 2016 4:39 AM To: Srivatsa, Anusha Cc:

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

On Fri, Sep 02, 2016 at 04:00:20PM +0300, Mika Kahola wrote: > On Thu, 2016-09-01 at 15:08 -0700, 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

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

On Fri, Sep 02, 2016 at 03:49:02PM +0300, David Weinehall wrote: > On Thu, Sep 01, 2016 at 03:08:16PM -0700, 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

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

On Fri, Sep 02, 2016 at 03:03:22PM +0300, David Weinehall wrote: > On Thu, Sep 01, 2016 at 03:08:16PM -0700, 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

[Intel-gfx] FIFO underruns

Hi, recently I started seeing occasional short screen flicker to black associated with dmesg entries [ 583.020853] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [13512.114363] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Re: [Intel-gfx] [PATCH 04/10] drm: Extract drm_plane.[hc]

On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter wrote: > Just pure code movement, cleanup and polish will happen in later > patches. > > v2: Don't forget all the ioctl! To extract those cleanly I decided to > put check_src_coords into drm_framebuffer.c (and give it a >

Re: [Intel-gfx] [PATCH 03/10] drm: Move all decl for drm_edid.c to drm_edid.h

On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter wrote: > Some were still left in drm_crtc.h. Also include drm_edid.h in the > rst files. > > Signed-off-by: Daniel Vetter Reviewed-by: Sean Paul > --- >

Re: [Intel-gfx] [PATCH 01/10] drm: Move a few macros away from drm_crtc.h

On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter wrote: > Now that there's less stuff in there I noticed that I overlooked them. > Sprinkle some docs over them while at it. > > Signed-off-by: Daniel Vetter Reviewed-by: Sean Paul

Re: [Intel-gfx] [PATCH 09/10] drm/doc: Document color space handling

On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter wrote: > Again move it from the unmaintainable csv into DOC free-form overview > sections. > > Cc: Lionel Landwerlin > Signed-off-by: Daniel Vetter A few more comment

Re: [Intel-gfx] [PATCH 07/10] drm/doc: Polish plane composition property docs

On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter wrote: > Try to spec a bit more precisely how they all fit together, now that > at least the code is for all the additional properties is in one > place. > > Also remove the entries for the standardized properties from the >

Re: [Intel-gfx] [PATCH 06/10] drm: Conslidate blending properties in drm_blend.[hc]

On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter wrote: > Imo zpos, rotatation, blending eq (once we have it) and all that > should be in drm_blend.c, since those are all about how exactly the > pixels are rendered onto the CRTC's visible area. Also noticed that > one

Re: [Intel-gfx] [PATCH 10/10] drm: Remove dirty property from docs

On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter wrote: > We removed it in > > commit 6ab10b76ff6252bd9be0849c40f5865e39a29961 > Author: Daniel Vetter > Date: Fri Aug 12 22:48:45 2016 +0200 > > drm/kms: Nuke dirty_info property > >

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On 06/09/16 16:33, Goel, Akash wrote: On 9/6/2016 6:47 PM, Tvrtko Ursulin wrote: Hi, On 06/09/16 11:43, akash.g...@intel.com wrote: From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On 9/6/2016 6:47 PM, Tvrtko Ursulin wrote: Hi, On 06/09/16 11:43, akash.g...@intel.com wrote: From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are pulled from a debugfs file

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove 64b mmio write vfuncs (rev2)

== Series Details == Series: drm/i915: Remove 64b mmio write vfuncs (rev2) URL : https://patchwork.freedesktop.org/series/12029/ State : failure == Summary == Series 12029v2 drm/i915: Remove 64b mmio write vfuncs http://patchwork.freedesktop.org/api/1.0/series/12029/revisions/2/mbox/ Test

[Intel-gfx] [PATCH i-g-t] benchmarks/gem_busy: Fix compile error

The benchmark was failing with: gem_busy.c:158:8: error: implicit declaration of function 'intel_gen' is invalid in C99 [-Werror,-Wimplicit-function-declaration] gen = intel_gen(intel_get_drm_devid(fd)); The root cause was due to the local lib directory not being specified in

[Intel-gfx] [CI] drm/i915: Remove 64b mmio write vfuncs

We don't have safe 64-bit mmio writes as they are really split into 2x32-bit writes. This tearing is dangerous as the hardware *will* operate on the intermediate value, requiring great care when assigning. (See, for example, i965_write_fence_reg.) As such we don't currently use them and strongly

Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

On Sat, Aug 27, 2016 at 02:33:25PM +0100, Matthew Auld wrote: > Currently it's entirely possible to go through the link training step > without first determining the lane_count, which is silly since we end up > doing a bunch of aux transfers of size = 0, as highlighted by > WARN_ON(!msg->buffer !=

Re: [Intel-gfx] [PATCH 0/2] GVT-g guest patch for 4.8

On Tue, 06 Sep 2016, Jani Nikula wrote: > On Tue, 06 Sep 2016, Zhenyu Wang wrote: >> [ Unknown signature status ] >> On 2016.09.06 11:33:57 +0300, Jani Nikula wrote: >>> On Tue, 06 Sep 2016, Chris Wilson wrote: >>>

Re: [Intel-gfx] [PATCH 0/2] GVT-g guest patch for 4.8

On Tue, 06 Sep 2016, Zhenyu Wang wrote: > [ Unknown signature status ] > On 2016.09.06 11:33:57 +0300, Jani Nikula wrote: >> On Tue, 06 Sep 2016, Chris Wilson wrote: >> > On Tue, Sep 06, 2016 at 12:04:10PM +0800, Zhenyu Wang wrote: >> >> Hi, >>

Re: [Intel-gfx] [PATCH v5 1/4] drm: two more (drm_)printk() wrapper macros

On Fri, Aug 26, 2016 at 1:50 PM, Dave Gordon wrote: > We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() > provides several other useful intermediate levels such as NOTICE and > WARNING. So this patch fills out the set by providing simple macros for

Re: [Intel-gfx] [PATCH] drm/i915: Try harder to reset the gen8+ engines

Chris Wilson writes: > On Tue, Sep 06, 2016 at 02:11:47PM +0300, Mika Kuoppala wrote: >> >> Resending my r-b... > > It's not enough, even retrying the reset a few times, we still > eventually get a timeout. > > This is just the usual > 10: 0x > 20:

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

Hi, On 06/09/16 11:43, akash.g...@intel.com wrote: From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and stored into a file

Re: [Intel-gfx] [PATCH 06/17] drm/i915: Move obj->dirty:1 to obj->flags

On Tue, Sep 06, 2016 at 12:37:33PM +0100, Dave Gordon wrote: > On 22/08/16 09:03, Chris Wilson wrote: > >The obj->dirty bit is a companion to the obj->active bits that were > >moved to the obj->flags bitmask. Since we also update this bit inside > >the i915_vma_move_to_active() hotpath, we can

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Store port enum in intel_encoder

On Wed, Aug 24, 2016 at 12:22:57AM -0700, Dhinakaran Pandiyan wrote: > Storing the port enum in intel_encoder makes it convenient to know the > port attached to an encoder. Moving the port information up from > intel_digital_port to intel_encoder avoids unecessary intel_digital_port > access and

Re: [Intel-gfx] [PATCH 06/17] drm/i915: Move obj->dirty:1 to obj->flags

On 22/08/16 09:03, Chris Wilson wrote: The obj->dirty bit is a companion to the obj->active bits that were moved to the obj->flags bitmask. Since we also update this bit inside the i915_vma_move_to_active() hotpath, we can aide gcc by also moving the obj->dirty bit to obj->flags bitmask.

Re: [Intel-gfx] [PATCH] drm/i915: Try harder to reset the gen8+ engines

On Tue, Sep 06, 2016 at 02:11:47PM +0300, Mika Kuoppala wrote: > > Resending my r-b... It's not enough, even retrying the reset a few times, we still eventually get a timeout. This is just the usual 10: 0x 20: goto 10 hanging batch > > Chris Wilson

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Cleanup instdone collection

Imre Deak writes: > From: Ben Widawsky > > Consolidate the instdone logic so we can get a bit fancier. This patch also > removes the duplicated print of INSTDONE[0]. > > v2: (Imre) > - Rebased on top of hangcheck INSTDONE changes. > - Move all

Re: [Intel-gfx] [PATCH] drm/i915: Try harder to reset the gen8+ engines

Resending my r-b... Chris Wilson writes: > If at first we don't succeed, try again. > > Running the reset and recovery routines in a loop ends in a "reset > request timeout" with a mtbf of an hour on Braswell. This is eerily > similar to the unrecoverable reset

[Intel-gfx] ✗ Fi.CI.BAT: warning for add the generic H.264 decoder settings controls

== Series Details == Series: add the generic H.264 decoder settings controls URL : https://patchwork.freedesktop.org/series/12045/ State : warning == Summary == Series 12045v1 add the generic H.264 decoder settings controls

[Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and stored into a file '/tmp/guc_log_dump.dat', the name of the output file can be

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

On 04/09/16 19:58, Nicolas Iooss wrote: When building the kernel with clang and some warning flags, the compiler reports that the return value of dcs_get_backlight() may be uninitialized: drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: variable 'data' is used uninitialized

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/1] drm/i915/dsi: silence a warning about uninitialized return value

== Series Details == Series: series starting with [1/1] drm/i915/dsi: silence a warning about uninitialized return value URL : https://patchwork.freedesktop.org/series/12044/ State : failure == Summary == Series 12044v1 Series without cover letter

Re: [Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

On 2016-09-06 11:25, Jani Nikula wrote: On Tue, 06 Sep 2016, li...@eikelenboom.it wrote: L.S., Since one of the last 4.8 RC's i'm getting the warning below when booting on my sandybridge based thinkpad. From what it seems the machine still works fine though. What does 'lspci -nns 2' say for

Re: [Intel-gfx] [PATCH 08/14] drm/i915/dp: Move max. vswing check to it's own function

On Fri, 2016-09-02 at 11:05 +0300, Mika Kahola wrote: > +1 for this cleanup > > Reviewed-by: Mika Kahola Received couple of compiler warnings to be cleaned up drivers/gpu/drm/i915/intel_dp_link_training.c: In function ‘intel_dp_link_max_vswing_reached’:

[Intel-gfx] [PATCH 2/2] v4l2-ctrls: add generic H.264 decoder codec settings structure

The generic decoder settings for H.264. It is modified from the VA-API. Adding the extra data required by the Rockchip. Signed-off-by: Randy Li --- include/uapi/linux/videodev2.h | 103 + 1 file changed, 103 insertions(+) diff --git

[Intel-gfx] [PATCH RFC 0/2] add the generic H.264 decoder settings controls

This is not done yet. The rockchip VA-API driver[1] still need a third part library to pre-parse the nalu data. Maybe after the third part library free version[2] had done, it would be clear that we else filed we may need. Those structures comes from VA-API SPCE. But still not enough to driver a

[Intel-gfx] [PATCH 1/2] [media] v4l2-ctrls: add H.264 decoder settings controls

These two controls would be used to set the H.264 codec settings for decoder. Signed-off-by: Randy Li --- drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++ include/uapi/linux/v4l2-controls.h | 2 ++ 2 files changed, 4 insertions(+) diff --git

[Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

When building the kernel with clang and some warning flags, the compiler reports that the return value of dcs_get_backlight() may be uninitialized: drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: variable 'data' is used uninitialized whenever 'for' loop exits because its

Re: [Intel-gfx] [PATCH 15/21] drm/i915: Reorder i915_add_request to separate the phases better

Chris Wilson writes: > Let's avoid mixing sealing the hardware commands for the request and > adding the request to the software tracking. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- >

Re: [Intel-gfx] [PATCH 12/21] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker

Chris Wilson writes: > Since we have a cooperative mode now with a direct reset, we can avoid > the contention on struct_mutex and instead try then sleep on the > I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is > cleared, all is fine. Otherwise, we

[Intel-gfx] [PATCH i-g-t 1/2][RFC] igt: avoid using PCIIDs defined in intel_chipset.h

Signed-off-by: Juha-Pekka Heikkila --- tests/gem_pipe_control_store_loop.c | 2 +- tests/kms_cursor_crc.c | 3 ++- tools/intel_error_decode.c | 2 +- tools/intel_stepping.c | 40 ++---

[Intel-gfx] [PATCH i-g-t 2/2][RFC] igt: define out PCIIDs from intel_chipset.h

Usage of these was removed on earlier patch. Signed-off-by: Juha-Pekka Heikkila --- lib/intel_chipset.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h index 1003266..ff903bf 100644 --- a/lib/intel_chipset.h +++

Re: [Intel-gfx] i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

> Meelis, what does 'lspci -nns 2' say for you? 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) > > BR, > Jani. > > On Tue, 06 Sep 2016, Jani Nikula wrote: > >

[Intel-gfx] [PATCH i-g-t 0/2][RFC] Take out PCIIDs from intel_chipset.h

I had interest to take out PCIIDs from intel_chipset.h in favor of i915_pciids.h, maybe some seasoned igt veteran can say what's the correct way. There are lot of magic numbers here and there but I'm not happy adding more magics into the code. Still seems most of these defines were used just once

Re: [Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

On Tue, 06 Sep 2016, li...@eikelenboom.it wrote: > L.S., > > Since one of the last 4.8 RC's i'm getting the warning below when > booting on my sandybridge based thinkpad. > From what it seems the machine still works fine though. What does 'lspci -nns 2' say for you? BR, Jani. > > -- > Sander

Re: [Intel-gfx] [PATCH 10/21] drm/i915: Mark up all locked waiters

Chris Wilson writes: > In the next patch we want to handle reset directly by a locked waiter in > order to avoid issues with returning before the reset is handled. To > handle the reset, we must first know whether we hold the struct_mutex. > If we do not hold the

Re: [Intel-gfx] i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

Meelis, what does 'lspci -nns 2' say for you? BR, Jani. On Tue, 06 Sep 2016, Jani Nikula wrote: > Lyude, this is due to > > commit 87660502f1a4d51fb043e89a45d30c9917787c22 > Author: Lyude > Date: Wed Aug 17 15:55:53 2016 -0400 > >

Re: [Intel-gfx] i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

Lyude, this is due to commit 87660502f1a4d51fb043e89a45d30c9917787c22 Author: Lyude Date: Wed Aug 17 15:55:53 2016 -0400 drm/i915/gen6+: Interpret mailbox error flags and on its way to stable. BR, Jani. On Mon, 29 Aug 2016, Meelis Roos wrote: >

Re: [Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

Lyude, this is due to commit 87660502f1a4d51fb043e89a45d30c9917787c22 Author: Lyude Date: Wed Aug 17 15:55:53 2016 -0400 drm/i915/gen6+: Interpret mailbox error flags and on its way to stable. BR, Jani. On Tue, 06 Sep 2016, li...@eikelenboom.it wrote: > L.S., > >

Re: [Intel-gfx] [PATCH 0/2] GVT-g guest patch for 4.8

On 2016.09.06 11:33:57 +0300, Jani Nikula wrote: > On Tue, 06 Sep 2016, Chris Wilson wrote: > > On Tue, Sep 06, 2016 at 12:04:10PM +0800, Zhenyu Wang wrote: > >> Hi, > >> > >> Here're two patches for GVT-g guest to fix run against future GVT-g > >> host driver, which

Re: [Intel-gfx] [PATCH 0/2] GVT-g guest patch for 4.8

On Tue, 06 Sep 2016, Chris Wilson wrote: > On Tue, Sep 06, 2016 at 12:04:10PM +0800, Zhenyu Wang wrote: >> Hi, >> >> Here're two patches for GVT-g guest to fix run against future GVT-g >> host driver, which try to ensure 4.8 will be ready to use for VM. >> >> thanks.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't wait for a spinlock inside error capture

== Series Details == Series: drm/i915: Don't wait for a spinlock inside error capture URL : https://patchwork.freedesktop.org/series/12033/ State : success == Summary == Series 12033v1 drm/i915: Don't wait for a spinlock inside error capture

[Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

L.S., Since one of the last 4.8 RC's i'm getting the warning below when booting on my sandybridge based thinkpad. From what it seems the machine still works fine though. -- Sander [2.846265] [ cut here ] [2.846280] WARNING: CPU: 0 PID: 4 at

Re: [Intel-gfx] [PATCH] drm/i915: Remove 64b mmio write vfuncs

On Tue, Sep 06, 2016 at 10:40:17AM +0300, Joonas Lahtinen wrote: > On ti, 2016-09-06 at 07:19 +0100, Chris Wilson wrote: > > @@ -3725,7 +3723,6 @@ int intel_freq_opcode(struct drm_i915_private > > *dev_priv, int val); > >   * act upon the intermediate value, possibly leading to corruption and > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: disable 48bit full PPGTT when vGPU is active

On ti, 2016-09-06 at 12:04 +0800, Zhenyu Wang wrote: > From: Zhi Wang > > Disable 48bit full PPGTT on vGPU too for now. > > Signed-off-by: Zhi Wang > Signed-off-by: Zhenyu Wang Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 1/2] drm/i915: enable vGPU detection for all

On ti, 2016-09-06 at 12:04 +0800, Zhenyu Wang wrote: > From: Ping Gao > > vGPU capability is handled by GVT-g host driver, not needed to > put extra HW check for vGPU detection. And we'll actually support > vGPU from BDW. > > Signed-off-by: Ping Gao

Re: [Intel-gfx] [PATCH] drm/i915: Don't wait for a spinlock inside error capture

On ti, 2016-09-06 at 08:38 +0100, Chris Wilson wrote: > If we can't grab the breadcrumb's spinlock, possibly due to a driver > deadlock inside the waiters, ignore them. Like hangcheck, error > capturing must work no matter how the driver/GPU dies. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Remove 64b mmio write vfuncs

On ti, 2016-09-06 at 07:19 +0100, Chris Wilson wrote: > @@ -3725,7 +3723,6 @@ int intel_freq_opcode(struct drm_i915_private > *dev_priv, int val); >   * act upon the intermediate value, possibly leading to corruption and >   * machine death. You have been warned. >   */ I'd update the comment,

[Intel-gfx] [PATCH] drm/i915: Don't wait for a spinlock inside error capture

If we can't grab the breadcrumb's spinlock, possibly due to a driver deadlock inside the waiters, ignore them. Like hangcheck, error capturing must work no matter how the driver/GPU dies. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gpu_error.c | 25

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

On Mon, 05 Sep 2016, Tvrtko Ursulin wrote: > On 05/09/16 16:06, Tvrtko Ursulin wrote: >> On 12/08/16 13:06, Dave Gordon wrote: >>> On 11/08/16 18:35, Patchwork wrote: == Series Details == Series: Reclassify messages from GuC loader/submission (rev3)

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove 64b mmio write vfuncs

== Series Details == Series: drm/i915: Remove 64b mmio write vfuncs URL : https://patchwork.freedesktop.org/series/12029/ State : failure == Summary == Series 12029v1 drm/i915: Remove 64b mmio write vfuncs http://patchwork.freedesktop.org/api/1.0/series/12029/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 0/2] GVT-g guest patch for 4.8

On Tue, Sep 06, 2016 at 12:04:10PM +0800, Zhenyu Wang wrote: > Hi, > > Here're two patches for GVT-g guest to fix run against future GVT-g > host driver, which try to ensure 4.8 will be ready to use for VM. > > thanks. > > Ping Gao (1): > drm/i915: enable vGPU detection for all > > Zhi Wang

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

On Tue, Sep 06, 2016 at 10:54:14AM +0530, Praveen Paneri wrote: > Decoupled MMIO is an alternative way to access forcewake domain > registers, which requires less cycles and avoids frequent software > forcewake. How about when forcewake is already held? You'll note that we still require

[Intel-gfx] [PATCH] drm/i915: Remove 64b mmio write vfuncs

We don't have safe 64-bit mmio writes as they are really split into 2x32-bit writes. This tearing is dangerous as the hardware *will* operate on the intermediate value, requiring great care when assigning. (See, for example, i965_write_fence_reg.) As such we don't currently use them and strongly