[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/dmc: Make no_stepping_info an array

== Series Details == Series: series starting with [1/2] drm/i915/dmc: Make no_stepping_info an array URL : https://patchwork.freedesktop.org/series/13818/ State : warning == Summary == Series 13818v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/1] drm/i915/guc: Sanitory checks for platform that dont have GuC

== Series Details == Series: series starting with [1/1] drm/i915/guc: Sanitory checks for platform that dont have GuC URL : https://patchwork.freedesktop.org/series/13815/ State : warning == Summary == Series 13815v1 Series without cover letter

[Intel-gfx] [PATCH 2/2] drm/i915/DMC/KBL: Load DMC on KBL using he no_stepping_info array

Currently, for display there is only one DMC image for KBL. Remove the stepping_info table for KBL and use the no_stepping_info for loading the firmware image. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa ---

[Intel-gfx] [PATCH 1/2] drm/i915/dmc: Make no_stepping_info an array

Make no_stepping_info an array of structs so that on plaforms that have only one binary of DMC, we can iterate through this array by having the same logic for firmware loads Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa ---

[Intel-gfx] [PATCH 1/1] drm/i915/guc: Sanitory checks for platform that dont have GuC

i915.enable_guc_loading/submission=2 forces the usage of GuC. For platforms that do not have a GuC, asking the kernel to use a GuC should not result in an error state. Do extra checks to see if the platform even has a GuC or not, regardless of the kernel parameter. v2: Based on Rodrigo's patch

[Intel-gfx] ✗ Fi.CI.BAT: warning for Start of skl watermark cleanup (rev3)

== Series Details == Series: Start of skl watermark cleanup (rev3) URL : https://patchwork.freedesktop.org/series/1/ State : warning == Summary == Series 1v3 Start of skl watermark cleanup https://patchwork.freedesktop.org/api/1.0/series/1/revisions/3/mbox/ Test kms_flip:

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: unconditionally apply the memory bandwidth WA

Reviewed-by: Lyude On Tue, 2016-10-11 at 15:25 -0300, Paulo Zanoni wrote: > Mahesh Kumar is already working on a proper implementation for the > workaround, but while we still don't have it, let's just > unconditionally apply the workaround for everybody and we hope we can >

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

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 reusable for the next patch. Changes since v1: - Fix accidental

[Intel-gfx] [PATCH v3 03/10] drm/i915/gen9: Make skl_wm_level per-plane

Having skl_wm_level contain all of the watermarks for each plane is annoying since it prevents us from having any sort of object to represent a single watermark level, something we take advantage of in the next commit to cut down on all of the copy paste code in here. Changes since v1: - Style

[Intel-gfx] [PATCH v2 04/10] drm/i915/gen9: Cleanup skl_pipe_wm_active_state

This function is a wreck, let's help it get its life back together and cleanup all of the copy pasta here. Signed-off-by: Lyude Reviewed-by: Maarten Lankhorst Reviewed-by: Paulo Zanoni Cc: Ville Syrjälä

[Intel-gfx] [PATCH v3 02/10] drm/i915/skl: Remove linetime from skl_wm_values

Next part of cleaning up the watermark code for skl. This is easy, since it seems that we never actually needed to keep track of the linetime in the skl_wm_values struct anyway. Signed-off-by: Lyude Reviewed-by: Paulo Zanoni Reviewed-by: Maarten

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

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 Cc: Ville Syrjälä

[Intel-gfx] [PATCH v3 01/10] drm/i915/skl: Move per-pipe ddb allocations into crtc states

First part of cleaning up all of the skl watermark code. This moves the structures for storing the ddb allocations of each pipe into intel_crtc_state, along with moving the structures for storing the current ddb allocations active on hardware into intel_crtc. Changes since v1: - Don't replace

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

Wrapping strings is against the guidelines in Documentation/CodingStyle, chapter 2. Signed-off-by: Lyude Reviewed-by: Paulo Zanoni Cc: Maarten Lankhorst Cc: Ville Syrjälä Cc: Matt

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

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 watermarks: one being the skl_pipe_wm structs, the other being the global wm struct in drm_i915_private containing the raw

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

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. Changes since v1: - Use %u instead of %d when printing WM state mismatches Signed-off-by: Lyude

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

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 Reviewed-by: Paulo Zanoni

[Intel-gfx] [PATCH v3 00/10] Start of skl watermark cleanup

While it (mostly) works, the code for handling watermarks on Skylake has been kind of ugly for a while. As well a lot of it isn't that friendly to atomic transactions, Lots of copy paste, redundant wm values, etc. While this isn't a full cleanup, it's a good start. As well, we add a couple of

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

On Fri, 2016-10-14 at 03:09 +, Yang, Libin wrote: > Tested-by: Libin Yang > > Regards, > Libin > > Thanks Libin. Can you confirm the max. BCLK frequency we set for the audio controller? -DK > > -Original Message- > > From: Intel-gfx

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

On Thu, 2016-10-13 at 21:44 +0300, Ville Syrjälä wrote: > 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

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

On Fri, 2016-10-14 at 11:40 +0300, Jani Nikula wrote: > On Thu, 13 Oct 2016, 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

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

On Thu, 2016-10-13 at 11:30 -0700, Jim Bride wrote: > 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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: WA to address the Ringbuffer coherency issue

== Series Details == Series: drm/i915/guc: WA to address the Ringbuffer coherency issue URL : https://patchwork.freedesktop.org/series/13807/ State : warning == Summary == Series 13807v1 drm/i915/guc: WA to address the Ringbuffer coherency issue

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

On Thu, 2016-10-13 at 15:28 -0300, Paulo Zanoni wrote: > 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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

== Series Details == Series: drm/i915: Suppress underrun reporting around DP link retraining URL : https://patchwork.freedesktop.org/series/13805/ State : warning == Summary == Series 13805v1 drm/i915: Suppress underrun reporting around DP link retraining

Re: [Intel-gfx] [PATCH] drm/i915/guc: WA to address the Ringbuffer coherency issue

On 10/14/2016 11:45 PM, Chris Wilson wrote: On Fri, Oct 14, 2016 at 11:53:44PM +0530, akash.g...@intel.com wrote: From: Akash Goel Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are pinned in mappable aperture portion of GGTT and for ringbuffer pages

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Simplify DP port limited color range bit platform checks

== Series Details == Series: drm/i915: Simplify DP port limited color range bit platform checks URL : https://patchwork.freedesktop.org/series/13803/ State : warning == Summary == Series 13803v1 drm/i915: Simplify DP port limited color range bit platform checks

Re: [Intel-gfx] [PATCH] drm/i915/guc: WA to address the Ringbuffer coherency issue

On Fri, Oct 14, 2016 at 11:53:44PM +0530, akash.g...@intel.com wrote: > From: Akash Goel > > Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are > pinned in mappable aperture portion of GGTT and for ringbuffer pages > allocated from Stolen memory, access

[Intel-gfx] [PATCH] drm/i915/guc: WA to address the Ringbuffer coherency issue

From: Akash Goel Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are pinned in mappable aperture portion of GGTT and for ringbuffer pages allocated from Stolen memory, access can only be done through GMADR BAR. In case of GuC based submission, updates done

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Document our internal limit on object size

== Series Details == Series: series starting with [1/2] drm/i915: Document our internal limit on object size URL : https://patchwork.freedesktop.org/series/13797/ State : warning == Summary == Series 13797v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Suppress underruns during DP link retraining

On Fri, Oct 14, 2016 at 06:27:49PM +0100, Chris Wilson wrote: > On Fri, Oct 14, 2016 at 08:02:54PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > DP link retraining causes (spurious?) underruns. We can't really avoid > > them, except

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/41] drm/i915: Move user fault tracking to a separate list

On Fri, Oct 14, 2016 at 05:20:14PM +, Saarinen, Jani wrote: > dmesg > [ 215.647898] BUG: unable to handle kernel paging request at fff0 > [ 215.647960] IP: [] drm_debugfs_crtc_add+0x10/0x90 0 haswell:/usr/src/linux (eb-fence)$ git grep drm_debugfs_crtc_add =1

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for RFC drm/i915: Add a sunset clause to GPU hang logging

On Fri, Oct 14, 2016 at 05:09:08PM +, Saarinen, Jani wrote: > > == Series Details == > > > > Series: RFC drm/i915: Add a sunset clause to GPU hang logging > > URL : https://patchwork.freedesktop.org/series/13788/ > > State : warning > > > > == Summary == > > > > Series 13788v1 RFC

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Suppress underruns during DP link retraining

On Fri, Oct 14, 2016 at 08:02:54PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > DP link retraining causes (spurious?) underruns. We can't really avoid > them, except perhaps by doing a full modeset (which has its own underrun > suppression

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Emit telltales for extra levels of debug upon initialisation

> == Series Details == > > Series: drm/i915: Emit telltales for extra levels of debug upon initialisation > URL : https://patchwork.freedesktop.org/series/13785/ > State : warning > > == Summary == > > Series 13785v1 drm/i915: Emit telltales for extra levels of debug upon > initialisation >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/41] drm/i915: Move user fault tracking to a separate list

> == Series Details == > > Series: series starting with [01/41] drm/i915: Move user fault tracking to a > separate list > URL : https://patchwork.freedesktop.org/series/13780/ > State : failure > > == Summary == > > Series 13780v1 Series without cover letter >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix cxsr_latency_table reorg

> == Series Details == > > Series: drm/i915: Fix cxsr_latency_table reorg > URL : https://patchwork.freedesktop.org/series/13789/ > State : warning > > == Summary == > > Series 13789v1 drm/i915: Fix cxsr_latency_table reorg >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for RFC drm/i915: Add a sunset clause to GPU hang logging

> == Series Details == > > Series: RFC drm/i915: Add a sunset clause to GPU hang logging > URL : https://patchwork.freedesktop.org/series/13788/ > State : warning > > == Summary == > > Series 13788v1 RFC drm/i915: Add a sunset clause to GPU hang logging >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Parse VBT data for lspcon

> == Series Details == > > Series: drm/i915: Parse VBT data for lspcon > URL : https://patchwork.freedesktop.org/series/13786/ > State : warning > > == Summary == > > Series 13786v1 drm/i915: Parse VBT data for lspcon > https://patchwork.freedesktop.org/api/1.0/series/13786/revisions/1/mbox/

[Intel-gfx] [PATCH 1/2] drm/i915: Extract intel_crtc_pch_transcoder()

From: Ville Syrjälä Extract the code to determine which PCH transcoder we're using to a small helper. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 21 ++---

[Intel-gfx] [PATCH 2/2] drm/i915: Suppress underruns during DP link retraining

From: Ville Syrjälä DP link retraining causes (spurious?) underruns. We can't really avoid them, except perhaps by doing a full modeset (which has its own underrun suppression anyway). So let's just hide them. MST still has its own logic for retrainin, but a

[Intel-gfx] [PATCH 0/2] drm/i915: Suppress underrun reporting around DP link retraining

From: Ville Syrjälä This series should reduce the underrn spam in CI. I expect it won't eliminate it entirely as we seem to have two classes of dmesg warns: from link retraining, and from normal modesets. The second category will need more investigation, but one

[Intel-gfx] ✗ Fi.CI.BAT: warning for Enable lspcon support for GEN9 devices (rev6)

== Series Details == Series: Enable lspcon support for GEN9 devices (rev6) URL : https://patchwork.freedesktop.org/series/8024/ State : warning == Summary == Series 8024v6 Enable lspcon support for GEN9 devices https://patchwork.freedesktop.org/api/1.0/series/8024/revisions/6/mbox/ Test

Re: [Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

Regards Shashank On 10/14/2016 8:02 PM, Jani Nikula wrote: On Fri, 14 Oct 2016, Shashank Sharma wrote: Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so

[Intel-gfx] [PATCH] drm/i915: Simplify DP port limited color range bit platform checks

From: Ville Syrjälä Instead of checking for everything not supporting the limited color range bit in the DP port register, let's check for the one thing that does have it (g4x). Signed-off-by: Ville Syrjälä ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix cxsr_latency_table reorg

== Series Details == Series: drm/i915: Fix cxsr_latency_table reorg URL : https://patchwork.freedesktop.org/series/13789/ State : warning == Summary == Series 13789v1 drm/i915: Fix cxsr_latency_table reorg https://patchwork.freedesktop.org/api/1.0/series/13789/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

On Fri, Oct 14, 2016 at 05:03:39PM +0100, Chris Wilson wrote: > > We could try to future proof more maybe like > > sizeof(typeof(obj->base.size)), is typeof can be used like that? > > Something similar for sg API if possible. But then again, it could > > be better future proofing to be hardcoded

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

On Fri, Oct 14, 2016 at 04:49:33PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 16:18, Chris Wilson wrote: > >In many places, we try to count pages using a 32 bit integer. That > >implies if we are asked to create an object larger than 43bits, we will > >subtly crash much later. Catch this on

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

On 14/10/2016 16:18, Chris Wilson wrote: In many places, we try to count pages using a 32 bit integer. That implies if we are asked to create an object larger than 43bits, we will subtly crash much later. Catch this on the boundary, and add a warning to remind ourselves later on our exabyte

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

On 14/10/2016 16:43, Chris Wilson wrote: On Fri, Oct 14, 2016 at 04:38:35PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 16:18, Chris Wilson wrote: The scattergather list uses a 32bit size counter, we should avoid exceeding it. Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

On Fri, Oct 14, 2016 at 04:38:35PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 16:18, Chris Wilson wrote: > >The scattergather list uses a 32bit size counter, we should avoid > >exceeding it. > > > >Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment > >size") >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

On 14/10/2016 16:24, Chris Wilson wrote: On Fri, Oct 14, 2016 at 04:18:10PM +0100, Chris Wilson wrote: In many places, we try to count pages using a 32 bit integer. That implies if we are asked to create an object larger than 43bits, we will subtly crash much later. Catch this on the boundary,

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

On 14/10/2016 16:18, Chris Wilson wrote: The scattergather list uses a 32bit size counter, we should avoid exceeding it. Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size") Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

On Fri, Oct 14, 2016 at 04:18:10PM +0100, Chris Wilson wrote: > In many places, we try to count pages using a 32 bit integer. That > implies if we are asked to create an object larger than 43bits, we will > subtly crash much later. Catch this on the boundary, and add a warning > to remind

[Intel-gfx] ✗ Fi.CI.BAT: warning for RFC drm/i915: Add a sunset clause to GPU hang logging

== Series Details == Series: RFC drm/i915: Add a sunset clause to GPU hang logging URL : https://patchwork.freedesktop.org/series/13788/ State : warning == Summary == Series 13788v1 RFC drm/i915: Add a sunset clause to GPU hang logging

[Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

The scattergather list uses a 32bit size counter, we should avoid exceeding it. Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size") Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1

[Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

In many places, we try to count pages using a 32 bit integer. That implies if we are asked to create an object larger than 43bits, we will subtly crash much later. Catch this on the boundary, and add a warning to remind ourselves later on our exabyte systems. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Parse VBT data for lspcon

== Series Details == Series: drm/i915: Parse VBT data for lspcon URL : https://patchwork.freedesktop.org/series/13786/ State : warning == Summary == Series 13786v1 drm/i915: Parse VBT data for lspcon https://patchwork.freedesktop.org/api/1.0/series/13786/revisions/1/mbox/ Test

[Intel-gfx] [PATCH igt] lib/igt_aux: Improve documentation for igt_system_suspend_autoresume()

While at it fix the order of states for consistency. Suggested by Daniel. Cc: Daniel Vetter Signed-off-by: Imre Deak --- lib/igt_aux.c | 21 - lib/igt_aux.h | 36 +++- 2 files changed, 51

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 14:53, Chris Wilson wrote: > >>>We do pass NORETRY | NOWARN for the higher order allocations, so it > >>>shouldn't be as bad it seems? > >>I don't know for sure without looking into the implementation > >>details.

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

On 14/10/2016 14:53, Chris Wilson wrote: On Fri, Oct 14, 2016 at 02:44:00PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 13:54, Chris Wilson wrote: On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 13:18, Chris Wilson wrote: + gfp = GFP_KERNEL | __GFP_HIGHMEM

Re: [Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

On Fri, 14 Oct 2016, Shashank Sharma wrote: > Many GEN9 boards come with on-board lspcon cards. > Fot these boards, VBT configuration should properly point out > if a particular port contains lspcon device, so that driver can > initialize it properly. > > This patch

[Intel-gfx] [PATCH v6 5/5] drm/i915: Add lspcon resume function

As per the software design, we are driving lspcon in PCON mode. But while resuming from suspend, lspcon can go in LS mode (which is its default operating mode on power on) This patch adds a resume function for lspcon, which makes sure its operating in PCON mode, post resume. V2: Address review

[Intel-gfx] [PATCH v6 0/5] Enable lspcon support for GEN9 devices

LSPCON is essentially a dp++->hdmi adapter with dual mode of operation. These modes are: - Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi passive dongle, which steps up DP++ output to appropriate HDMI 1.4 signal. This mode doesn't do any conversion at the protocol level. -

[Intel-gfx] [PATCH v6 1/5] drm: Helper for lspcon in drm_dp_dual_mode

This patch adds lspcon support in dp_dual_mode helper. lspcon is essentially a dp->hdmi dongle with dual personality. LS mode: It works as a passive dongle, by level shifting DP++ signals to HDMI signals, in LS mode. PCON mode: It works as a protocol converter active dongle in pcon mode, by

[Intel-gfx] [PATCH v6 2/5] drm/i915: Add lspcon support for I915 driver

This patch adds a new file, to accommodate lspcon support for I915 driver. These functions probe, detect, initialize and configure an on-board lspcon device during the driver init time. Also, this patch adds a small structure for lspcon device, which will provide the runtime status of the device.

[Intel-gfx] [PATCH v6 4/5] drm/i915: Enable lspcon initialization

This patch adds initialization code for lspcon. What we are doing here is: - Check if lspcon is configured in VBT for this port - If lspcon is configured, initialize it and configure it as DP port. V2: Addressed Ville's review comments: - Not adding AVI IF functions for

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Emit telltales for extra levels of debug upon initialisation

== Series Details == Series: drm/i915: Emit telltales for extra levels of debug upon initialisation URL : https://patchwork.freedesktop.org/series/13785/ State : warning == Summary == Series 13785v1 drm/i915: Emit telltales for extra levels of debug upon initialisation

Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

On Fri, 14 Oct 2016, Tvrtko Ursulin wrote: > On 14/10/2016 14:31, Jani Nikula wrote: >> On Thu, 13 Oct 2016, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> unsigned long is too wide - use smaller types in

[Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so that driver can initialize it properly. This patch adds a utility function, which checks the VBT flag for lspcon bit, and tells us if a

Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

On Fri, Oct 14, 2016 at 03:08:29PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 14:31, Jani Nikula wrote: > >On Thu, 13 Oct 2016, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>unsigned long is too wide - use smaller types in > >>struct

Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

On 14/10/2016 14:31, Jani Nikula wrote: On Thu, 13 Oct 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin unsigned long is too wide - use smaller types in struct cxsr_latency to save 800-something bytes of .rodata. v2: All data even fits in u16

Re: [Intel-gfx] [PATCH 14/41] drm/i915: Use a radixtree for random access to the object's backing storage

On Fri, Oct 14, 2016 at 02:32:03PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 13:18, Chris Wilson wrote: > >A while ago we switched from a contiguous array of pages into an sglist, > >for that was both more convenient for mapping to hardware and avoided > >the requirement for a vmalloc array

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

On Fri, Oct 14, 2016 at 02:44:00PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 13:54, Chris Wilson wrote: > >On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: > >>On 14/10/2016 13:18, Chris Wilson wrote: > >>>+ gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE; > >>>+ if

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/41] drm/i915: Move user fault tracking to a separate list

== Series Details == Series: series starting with [01/41] drm/i915: Move user fault tracking to a separate list URL : https://patchwork.freedesktop.org/series/13780/ State : failure == Summary == Series 13780v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915: Fix cxsr_latency_table reorg

From: Tvrtko Ursulin I have re-ordered some struct members in patch: commit 44a655cae3043453f9dd8076538712d52e2e0ce4 Author: Tvrtko Ursulin Date: Thu Oct 13 11:09:23 2016 +0100 drm/i915: Shrink cxsr_latency_table but that

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

On Fri, 14 Oct 2016, Ville Syrjälä wrote: > On Thu, Oct 13, 2016 at 02:38:30PM -0500, Pierre-Louis Bossart wrote: >> 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.

[Intel-gfx] [PATCH] RFC drm/i915: Add a sunset clause to GPU hang logging

If the kernel is old, more than a few releases old, chances are that the user is using an old kernel for a good reason, despite there being GPU hangs. After 180days since driver release stop suggesting that they should send those reports upstream. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

On 14/10/2016 13:54, Chris Wilson wrote: On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 13:18, Chris Wilson wrote: + gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE; + if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) { + /* 965gm

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

I was about to send another series to address Imre's patches. There I have addressed this problems. Please wait for some time, I will re-sync and send V6 for all patches. Even though I am not sure why it dint apply on nightly, as I did a git-pull few hours ago. Regards Shashank

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

On Fri, 14 Oct 2016, Patchwork wrote: > == Series Details == > > Series: Enable lspcon support for GEN9 devices (rev5) > URL : https://patchwork.freedesktop.org/series/8024/ > State : failure > > == Summary == > > LD drivers/thermal/built-in.o > LD

Re: [Intel-gfx] [PATCH 15/41] drm/i915: Use radixtree to jump start intel_partial_pages()

On 14/10/2016 13:18, Chris Wilson wrote: We can use the radixtree index of the obj->pages to find the start position of the desired partial range. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_gtt.c | 40 - 1

Re: [Intel-gfx] [PATCH] drm/i915: Parse VBT data for lspcon

On Fri, 14 Oct 2016, Jani Nikula wrote: > From: Shashank Sharma > > Many GEN9 boards come with on-board lspcon cards. > Fot these boards, VBT configuration should properly point out > if a particular port contains lspcon device, so that driver

[Intel-gfx] [PATCH] drm/i915: Parse VBT data for lspcon

From: Shashank Sharma Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so that driver can initialize it properly. This patch adds a utility function, which

Re: [Intel-gfx] [PATCH 14/41] drm/i915: Use a radixtree for random access to the object's backing storage

On 14/10/2016 13:18, Chris Wilson wrote: A while ago we switched from a contiguous array of pages into an sglist, for that was both more convenient for mapping to hardware and avoided the requirement for a vmalloc array of pages on every object. However, certain GEM API calls (like pwrite,

Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

On Thu, 13 Oct 2016, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > unsigned long is too wide - use smaller types in > struct cxsr_latency to save 800-something bytes of .rodata. > > v2: All data even fits in u16 for even more saving. (Ville

[Intel-gfx] [PATCH] drm/i915: Emit telltales for extra levels of debug upon initialisation

After printing our welcome message to the user, also include supplementary details on what debugging is enabled (useful for us to sanity check what extra safeguards are on for any random kernel). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 4

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/5] drm/i915: Move user fault tracking to a separate list

== Series Details == Series: series starting with [v2,1/5] drm/i915: Move user fault tracking to a separate list URL : https://patchwork.freedesktop.org/series/13775/ State : success == Summary == Series 13775v1 Series without cover letter

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

On Fri, 14 Oct 2016, Petri Latvala wrote: > On Fri, Oct 14, 2016 at 02:50:49PM +0300, Jani Nikula wrote: >> On Fri, 14 Oct 2016, Petri Latvala wrote: >> > On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote: >> >> While at it, make

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Adding intel_panel_scale_none() helper function

On 14.08.2015 08:18, Zhang, Xiong Y wrote: >> On Mon, Aug 10, 2015 at 06:23:19PM +, Rodrigo Vivi wrote: >>> I believe this function could be added along with the next patch that >>> is the first to use it... >>> Or it would be good to have a good commit message explaining why this >>> function

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 13:18, Chris Wilson wrote: > >+gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE; > >+if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) { > >+/* 965gm cannot relocate objects above 4GiB. */ > >+

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

On 14/10/2016 13:18, Chris Wilson wrote: Quite a few of our objects used for internal hardware programming do not benefit from being swappable or from being zero initialised. As such they do not benefit from using a shmemfs backing storage and since they are internal and never directly exposed

Re: [Intel-gfx] [PATCH v5 5/5] drm/i915: Add lspcon resume function

Regards Shashak On 10/14/2016 2:56 PM, Imre Deak wrote: On pe, 2016-10-14 at 14:54 +0530, Shashank Sharma wrote: As per the software design, we are driving lspcon in PCON mode. But while resuming from suspend, lspcon can go in LS mode (which is its default operating mode on power on) This

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

== Series Details == Series: Enable lspcon support for GEN9 devices (rev5) URL : https://patchwork.freedesktop.org/series/8024/ State : failure == Summary == LD drivers/thermal/built-in.o LD drivers/iommu/built-in.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o In file

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

On Fri, Oct 14, 2016 at 02:50:49PM +0300, Jani Nikula wrote: > On Fri, 14 Oct 2016, Petri Latvala wrote: > > On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote: > >> While at it, make debugfs_path point at the debugfs root, not > >> dri. This'll be handy in

[Intel-gfx] [PATCH 36/41] drm/i915: Create a unique name for the context

This will be used for communicating issues with this context to userspace, so we want to identify the parent process and the individual context. Note that the name isn't quite unique, it makes the presumption of there only being a single device fd per process. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 33/41] drm/i915: Record space required for breadcrumb emission

In the next patch, we will use deferred breadcrumb emission. That requires reserving sufficient space in the ringbuffer to emit the breadcrumb, which first requires us to know how large the breadcrumb is. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH 15/41] drm/i915: Use radixtree to jump start intel_partial_pages()

We can use the radixtree index of the obj->pages to find the start position of the desired partial range. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_gtt.c | 40 - 1 file changed, 26 insertions(+), 14 deletions(-)

[Intel-gfx] [PATCH 22/41] drm/i915: Acquire the backing storage outside of struct_mutex in set-domain

As we can locklessly (well struct_mutex-lessly) acquire the backing storage, do so in set-domain-ioctl to reduce the contention on the struct_mutex. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH 23/41] drm/i915: Move object release to a freelist + worker

We want to hide the latency of releasing objects and their backing storage from the submission, so we move the actual free to a worker. This allows us to switch to struct_mutex freeing of the object in the next patch. Furthermore, if we know that the object we are dereferencing remains valid for

  1   2   >