[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() (rev2)

== Series Details == Series: series starting with [v2,1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() (rev2) URL : https://patchwork.freedesktop.org/series/50113/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4875_full -> Patchwork_10280_full = ==

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() (rev2)

== Series Details == Series: series starting with [v2,1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() (rev2) URL : https://patchwork.freedesktop.org/series/50113/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4875 -> Patchwork_10280 = == Summary -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() (rev2)

== Series Details == Series: series starting with [v2,1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() (rev2) URL : https://patchwork.freedesktop.org/series/50113/ State : warning == Summary == $ dim checkpatch origin/drm-tip 96702d287245 drm/i915/dp: Fix link

[Intel-gfx] [PATCH v3 4/6] drm/i915/dp: Do not grab crtc modeset lock in intel_dp_detect()

A crtc modeset lock was added for link retraining but intel_dp_retrain_link() knows to take the necessary locks since commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") v2: Drop AUX power domain reference in the early return path Fixes: c85d200e8321

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/dp: Kill intel_dp->detect_done flag

On Tue, 2018-09-25 at 20:53 +0300, Ville Syrjälä wrote: > On Mon, Sep 24, 2018 at 03:45:27PM -0700, Dhinakaran Pandiyan wrote: > > The intel_dp->detect_done flag is no more useful. Pull > > intel_dp_long_pulse() into the lone caller, > > > > Cc: Jani Nikula > > Cc: Ville Syrjälä > >

[Intel-gfx] [PATCH v3 4/6] drm/i915/dp: Do not grab crtc modeset lock in intel_dp_detect()

A crtc modeset lock was added for link retraining but intel_dp_retrain_link() knows to take the necessary locks since commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") v2: Drop AUX power domain reference in the early return path Fixes: c85d200e8321

Re: [Intel-gfx] [PATCH 1/1] initial panel_power_off_time should be 0

Thank you very much for getting involved. 在 2018-09-25二的 17:53 +0300，Ville Syrjälä写道： On Tue, Sep 25, 2018 at 12:55:04PM +0300, Jani Nikula wrote: On Thu, 20 Sep 2018, ning.a.zh...@intel.com wrote: From: Zhang Ning mailto:ning.a.zh...@intel.com>> power on

Re: [Intel-gfx] [PATCH] drm/i915: Apply correct ddi translation table for AML device

On Tue, 2018-09-25 at 21:20, Souza, Jose wrote: >> Amber Lake used the same gen graphics as Kaby Lake. Kernel driver >> should configure KBL's DDI buffer setting for AML ULX as well. >> >> So far, driver would load DDI translation table that used for KBL H/S >> platform and apply it on AML

Re: [Intel-gfx] [PATCH] drm/i915: Add new AML_ULX support list

On Tue, 2018-09-25 at 21:18 -0700, Souza, Jose wrote: >> According to patch "drm/i915/aml: Introducing Amber Lake platform" >> (e364672477a1). Add a new marco for AML ULX GT2 devices. > >Just to confirm, there is a newly added Amber lake id( >https://patchwork.freedesktop.org/series/50037/)

Re: [Intel-gfx] [PATCH v4] drm/i915: Remove i915.enable_ppgtt override

No. We changed to full 48bit ppgtt long time ago. :) > -Original Message- > From: Wang, Zhi A > Sent: Wednesday, September 26, 2018 2:01 AM > To: Joonas Lahtinen ; Chris Wilson > ; intel-gfx@lists.freedesktop.org; Zhenyu Wang > > Cc: Auld, Matthew ; He, Min > Subject: Re: [PATCH v4]

Re: [Intel-gfx] [PATCH 2/3] drm/i915: make the primary plane func structs const

Em Ter, 2018-09-25 às 15:05 +0300, Ville Syrjälä escreveu: > On Mon, Sep 24, 2018 at 05:19:12PM -0700, Paulo Zanoni wrote: > > Because we can, the places where we use them already expect const > > structs. > > https://patchwork.freedesktop.org/series/44104/ already has the rest > of > the series

Re: [Intel-gfx] [PATCH 1/3] drm/i915: DRM_FORMAT_C8 is not possible with Yf tiling

Em Ter, 2018-09-25 às 15:02 +0300, Ville Syrjälä escreveu: > On Mon, Sep 24, 2018 at 05:19:11PM -0700, Paulo Zanoni wrote: > > Function intel_framebuffer_init() checks for the possibilities > > during > > framebuffer creation (addfb ioctl time). It is missing the fact > > that > > the indexed

Re: [Intel-gfx] [PATCH] drm/i915: Add new AML_ULX support list

On Tue, 2018-09-25 at 01:47 -0700, Lee, Shawn C wrote: > According to patch "drm/i915/aml: Introducing Amber Lake platform" > (e364672477a1). Add a new marco for AML ULX GT2 devices. Just to confirm, there is a newly added Amber lake id( https://patchwork.freedesktop.org/series/50037/) 0x87CA

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: GTT remapping for display

== Series Details == Series: drm/i915: GTT remapping for display URL : https://patchwork.freedesktop.org/series/50165/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4875_full -> Patchwork_10279_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH] drm/i915: Apply correct ddi translation table for AML device

On Tue, 2018-09-25 at 02:20 -0700, Lee, Shawn C wrote: > Amber Lake used the same gen graphics as Kaby Lake. Kernel driver > should configure KBL's DDI buffer setting for AML ULX as well. > > So far, driver would load DDI translation table that used for > KBL H/S platform and apply it on AML

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ handling

On Mon, 2018-09-24 at 15:45 -0700, Dhinakaran Pandiyan wrote: > There are two copies of the same code called from long and short > pulse handlers. Reviewed-by: José Roberto de Souza > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_dp.c | 59

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/dp: Do not grab crtc modeset lock in intel_dp_detect()

On Mon, 2018-09-24 at 15:45 -0700, Dhinakaran Pandiyan wrote: > A crtc modeset lock was added for link retraining but > intel_dp_retrain_link() knows to take the necessary locks since > commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the > ->post_hotplug() hook") > > Fixes:

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/dp: Use a local variable for intel_encoder *

On Mon, 2018-09-24 at 15:45 -0700, Dhinakaran Pandiyan wrote: > We have two cases of intel_dp to intel_encoder conversions, use a > local variable to store the conversion. > Reviewed-by: José Roberto de Souza > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_dp.c | 8

Re: [Intel-gfx] [PATCH v3 5/8] drm/i915/selftests: Add live vma selftest

Quoting Ville Syrjala (2018-09-25 20:37:11) > From: Ville Syrjälä > > Add a live selftest to excercise rotated/remapped vmas. We simply > write through the rotated/remapped vma, and confirm that the data > appears in the right page when read through the normal vma. > > Not sure what the fallout

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: GTT remapping for display

== Series Details == Series: drm/i915: GTT remapping for display URL : https://patchwork.freedesktop.org/series/50165/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4875 -> Patchwork_10279 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10279 need

Re: [Intel-gfx] [PATCH v3 1/8] drm/i915: Make sure fb gtt offsets stay within 32bits

Quoting Ville Syrjala (2018-09-25 20:37:07) > From: Ville Syrjälä > > Let's try to make sure the fb offset computations never hit > an integer overflow by making sure the entire fb stays > below 32bits. framebuffer_check() in the core already does > the same check, but as it doesn't know about

Re: [Intel-gfx] [PATCH v3 4/8] drm/i915/selftests: Add mock selftest for remapped vmas

Quoting Ville Syrjala (2018-09-25 20:37:10) > From: Ville Syrjälä > > Extend the rotated vma mock selftest to cover remapped vmas as > well. > > TODO: reindent the loops I guess? Left like this for now to > ease review > > Signed-off-by: Ville Syrjälä > --- >

Re: [Intel-gfx] [PATCH v3 5/8] drm/i915/selftests: Add live vma selftest

Quoting Ville Syrjala (2018-09-25 20:37:11) > From: Ville Syrjälä > > Add a live selftest to excercise rotated/remapped vmas. We simply > write through the rotated/remapped vma, and confirm that the data > appears in the right page when read through the normal vma. > > Not sure what the fallout

Re: [Intel-gfx] [PATCH 2/7] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v3.

On Tue, Sep 25, 2018 at 09:34:29PM +0300, Ville Syrjälä wrote: > On Tue, Sep 25, 2018 at 11:01:32AM -0700, Matt Roper wrote: > > On Mon, Sep 24, 2018 at 04:18:10PM +0300, Ville Syrjälä wrote: > > > On Mon, Sep 24, 2018 at 02:35:13PM +0200, Maarten Lankhorst wrote: > > > > Op 21-09-18 om 21:31

Re: [Intel-gfx] [PATCH v3 7/8] drm/i915: Bump gen4+ fb stride limit to 256KiB

Quoting Ville Syrjala (2018-09-25 20:37:13) > From: Ville Syrjälä > > With gtt remapping plugged in we can simply raise the stride > limit on gen4+. Let's just arbitraily pick 256 KiB as the limit. > > No remapping CCS because the virtual address of each page actually > matters due to the new

Re: [Intel-gfx] [PATCH] drm/i915: Redefine some Whiskey Lake SKUs

On Mon, 2018-09-24 at 16:43 -0700, Rodrigo Vivi wrote: > commit 'b9be78531d27 ("drm/i915/whl: Introducing > Whiskey Lake platform")' introduced WHL by moving some > of CFL IDs here and using the Spec information of "U43" for > most of IDs what appeared to be GT3. > > However when propagating the

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: GTT remapping for display

== Series Details == Series: drm/i915: GTT remapping for display URL : https://patchwork.freedesktop.org/series/50165/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Make sure fb gtt offsets stay within 32bits +drivers/gpu/drm/i915/intel_display.c:2416:13: error:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GTT remapping for display

== Series Details == Series: drm/i915: GTT remapping for display URL : https://patchwork.freedesktop.org/series/50165/ State : warning == Summary == $ dim checkpatch origin/drm-tip fd6c4b3fa1e9 drm/i915: Make sure fb gtt offsets stay within 32bits dafb1135ed8c drm/i915: Decouple SKL stride

Re: [Intel-gfx] [PATCH v3 8/8] drm/i915: Bump gen7+ fb size limits to 16kx16k

Quoting Ville Syrjala (2018-09-25 20:37:14) > From: Ville Syrjälä > > With gtt remapping in place we can use arbitrarily large > framebuffers. Let's bump the limits to 16kx16k on gen7+. > The limit was chosen to match the maximum 2D surface size > of the 3D engine. > > With the remapping we

[Intel-gfx] [PATCH v3 0/8] drm/i915: GTT remapping for display

From: Ville Syrjälä Another gtt remapping posting. Changes since the last time: - split out the plane stride check function (already in) - use add_overflows() (after massaging it a bit) - include some selftests for the remapped/rotated vmas - reduce the max fb size to 16kx16k on gen7+ due to

[Intel-gfx] [PATCH v3 7/8] drm/i915: Bump gen4+ fb stride limit to 256KiB

From: Ville Syrjälä With gtt remapping plugged in we can simply raise the stride limit on gen4+. Let's just arbitraily pick 256 KiB as the limit. No remapping CCS because the virtual address of each page actually matters due to the new hash mode (WaCompressedResourceDisplayNewHashMode:skl,kbl

[Intel-gfx] [PATCH v3 2/8] drm/i915: Decouple SKL stride units from intel_fb_stride_alignment()

From: Ville Syrjälä In the future framebuffer stride alignment requirements won't exactly match the units in which skl+ plane stride is specified. So extract the code for the skl+ stuff into a separate helper. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 28

[Intel-gfx] [PATCH v3 4/8] drm/i915/selftests: Add mock selftest for remapped vmas

From: Ville Syrjälä Extend the rotated vma mock selftest to cover remapped vmas as well. TODO: reindent the loops I guess? Left like this for now to ease review Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/selftests/i915_vma.c | 70 --- 1 file changed, 65

[Intel-gfx] [PATCH v3 5/8] drm/i915/selftests: Add live vma selftest

From: Ville Syrjälä Add a live selftest to excercise rotated/remapped vmas. We simply write through the rotated/remapped vma, and confirm that the data appears in the right page when read through the normal vma. Not sure what the fallout of making all rotated/remapped vmas mappable/fenceable

[Intel-gfx] [PATCH v3 8/8] drm/i915: Bump gen7+ fb size limits to 16kx16k

From: Ville Syrjälä With gtt remapping in place we can use arbitrarily large framebuffers. Let's bump the limits to 16kx16k on gen7+. The limit was chosen to match the maximum 2D surface size of the 3D engine. With the remapping we could easily go higher than that for the display engine.

[Intel-gfx] [PATCH v3 6/8] drm/i915: Overcome display engine stride limits via GTT remapping

From: Ville Syrjälä The display engine stride limits are getting in our way. On SKL+ we are limited to 8k pixels, which is easily exceeded with three 4k displays. To overcome this limitation we can remap the pages in the GTT to provide the display engine with a view of memory with a smaller

[Intel-gfx] [PATCH v3 1/8] drm/i915: Make sure fb gtt offsets stay within 32bits

From: Ville Syrjälä Let's try to make sure the fb offset computations never hit an integer overflow by making sure the entire fb stays below 32bits. framebuffer_check() in the core already does the same check, but as it doesn't know about tiling some things can slip through. Repeat the check in

[Intel-gfx] [PATCH v3 3/8] drm/i915: Add a new "remapped" gtt_view

From: Ville Syrjälä To overcome display engine stride limits we'll want to remap the pages in the GTT. To that end we need a new gtt_view type which is just like the "rotated" type except not rotated. v2: Use intel_remapped_plane_info base type s/unused/unused_mbz/ (Chris) Separate

Re: [Intel-gfx] [PATCH 2/7] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v3.

On Tue, Sep 25, 2018 at 11:01:32AM -0700, Matt Roper wrote: > On Mon, Sep 24, 2018 at 04:18:10PM +0300, Ville Syrjälä wrote: > > On Mon, Sep 24, 2018 at 02:35:13PM +0200, Maarten Lankhorst wrote: > > > Op 21-09-18 om 21:31 schreef Ville Syrjälä: > > > > On Fri, Sep 21, 2018 at 09:35:52PM +0300,

Re: [Intel-gfx] [PATCH v4] drm/i915: Remove i915.enable_ppgtt override

Hi Min: I remembered the IOTG guest kernel is using aliasing-ppgtt in the last technical sharing (probably I didn't remember it correctly). Can you confirm? Also, thanks Joonas for the reminding. :) thanks, Zhi. On 09/25/18 09:22, Joonas Lahtinen wrote: + Zhi and Zhenyu For me the patch

Re: [Intel-gfx] [PATCH 2/7] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v3.

On Mon, Sep 24, 2018 at 04:18:10PM +0300, Ville Syrjälä wrote: > On Mon, Sep 24, 2018 at 02:35:13PM +0200, Maarten Lankhorst wrote: > > Op 21-09-18 om 21:31 schreef Ville Syrjälä: > > > On Fri, Sep 21, 2018 at 09:35:52PM +0300, Ville Syrjälä wrote: > > >> On Fri, Sep 21, 2018 at 07:39:40PM +0200,

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/dp: Kill intel_dp->detect_done flag

On Mon, Sep 24, 2018 at 03:45:27PM -0700, Dhinakaran Pandiyan wrote: > The intel_dp->detect_done flag is no more useful. Pull > intel_dp_long_pulse() into the lone caller, > > Cc: Jani Nikula > Cc: Ville Syrjälä > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_dp.c |

Re: [Intel-gfx] [PULL] gvt-fixes for 4.19-rc5

Thanks for the reminder. :) So much appreciate. :) I just got two small code changes which hasn't been tested by QA. So I guess you can send the pull request first. Thanks again for the kindly reminding. :) thanks, Zhi. On 09/19/18 02:34, Joonas Lahtinen wrote: Just a reminder, if you are

Re: [Intel-gfx] [PATCH 5/8] drm/i915/psr: Do not enable PSR2 if sink requires selective update X granularity

On Mon, 2018-09-24 at 23:23 -0700, dhinakaran.pandi...@gmail.com wrote: > On Thu, 2018-09-20 at 13:43 -0700, José Roberto de Souza wrote: > > According to eDP spec, sink could required a granularity in the > > start of x coordinate or in the width of the selective update > > region. > > As it is

Re: [Intel-gfx] [PATCH] drm/i915/fbc: Disable fbc with VT-d also with kbl and cfl

On Tue, Sep 25, 2018 at 04:38:03PM +0300, Mika Kuoppala wrote: > Using fbc with VT-d flickers also on kbl and cfl. > > Cc: Paulo Zanoni > Cc: Ville Syrjälä > Cc: Chris Wilson > Cc: Rodrigo Vivi > Cc: # v4.9+ > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_fbc.c | 5 +++--

Re: [Intel-gfx] [PATCH 1/1] initial panel_power_off_time should be 0

On Tue, Sep 25, 2018 at 12:55:04PM +0300, Jani Nikula wrote: > On Thu, 20 Sep 2018, ning.a.zh...@intel.com wrote: > > From: Zhang Ning > > > > power on an eDP panel requests eDP panal fully powered off. > > need to wait t11_t12 after LCDVCC is off. usually t12 is 500ms. > > > > code, intel_dp.c,

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable RGB565 90/270 plane rotation for gen11 onwards.

On 25.09.2018 16:35, Maarten Lankhorst wrote: Op 05-09-18 om 16:58 schreef Ville Syrjälä: On Mon, Aug 27, 2018 at 03:37:53PM +0300, Juha-Pekka Heikkila wrote: From gen11 onwards RGB565 90/270 plane rotation is supported on hardware. IGT: https://patchwork.freedesktop.org/series/48756/

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/fbc: Disable fbc with VT-d also with kbl and cfl

== Series Details == Series: drm/i915/fbc: Disable fbc with VT-d also with kbl and cfl URL : https://patchwork.freedesktop.org/series/50147/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4874 -> Patchwork_10278 = == Summary - FAILURE == Serious unknown changes coming

[Intel-gfx] [PATCH] drm/i915/fbc: Disable fbc with VT-d also with kbl and cfl

Using fbc with VT-d flickers also on kbl and cfl. Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: Chris Wilson Cc: Rodrigo Vivi Cc: # v4.9+ Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_fbc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable RGB565 90/270 plane rotation for gen11 onwards.

Op 05-09-18 om 16:58 schreef Ville Syrjälä: > On Mon, Aug 27, 2018 at 03:37:53PM +0300, Juha-Pekka Heikkila wrote: >> From gen11 onwards RGB565 90/270 plane rotation is supported on hardware. >> >> IGT: https://patchwork.freedesktop.org/series/48756/ >> Signed-off-by: Juha-Pekka Heikkila >> ---

Re: [Intel-gfx] [PATCH v4] drm/i915: Remove i915.enable_ppgtt override

Quoting Chris Wilson (2018-09-25 14:48:20) > Now that we are confident in providing full-ppgtt where supported, > remove the ability to override the context isolation. > > v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted. > v3: s/USES/HAS/ to match usage and reject attempts

Re: [Intel-gfx] [PATCH v4] drm/i915: Remove i915.enable_ppgtt override

+ Zhi and Zhenyu For me the patch looks ok. It refuses to load GVT on systems where 48-bit is not supported, for not worsening the system security when virtualization is enabled (as anybody would probably expect virtualization to improve that). Please see code. Do we have such systems in the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove i915.enable_ppgtt override

== Series Details == Series: drm/i915: Remove i915.enable_ppgtt override URL : https://patchwork.freedesktop.org/series/50143/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4873 -> Patchwork_10277 = == Summary - FAILURE == Serious unknown changes coming with

Re: [Intel-gfx] [PATCH 2/7] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v3.

On Tue, Sep 25, 2018 at 12:03:47PM +0200, Maarten Lankhorst wrote: > Op 24-09-18 om 15:18 schreef Ville Syrjälä: > > On Mon, Sep 24, 2018 at 02:35:13PM +0200, Maarten Lankhorst wrote: > >> Op 21-09-18 om 21:31 schreef Ville Syrjälä: > >>> On Fri, Sep 21, 2018 at 09:35:52PM +0300, Ville Syrjälä

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove i915.enable_ppgtt override

== Series Details == Series: drm/i915: Remove i915.enable_ppgtt override URL : https://patchwork.freedesktop.org/series/50143/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4873 -> Patchwork_10276 = == Summary - FAILURE == Serious unknown changes coming with

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2)

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2) URL : https://patchwork.freedesktop.org/series/50137/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4872_full -> Patchwork_10275_full = == Summary - WARNING == Minor

Re: [Intel-gfx] [PATCH 18/40] drm/i915: Report the number of closed vma held by each context in debugfs

Quoting Tvrtko Ursulin (2018-09-24 12:57:31) > > On 19/09/2018 20:55, Chris Wilson wrote: > > Include the total size of closed vma when reporting the per_ctx_stats of > > debugfs/i915_gem_objects. > > Why do we need/want this? Removing extra locks, reducing struct_mutex coverage and because it

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Do not get aux power for disconnected DP ports

On Mon, Sep 24, 2018 at 06:16:49PM -0700, José Roberto de Souza wrote: > For ICL type-c ports there is a aux power restriction, it can only be > enabled while there is sink connected. That can't be entirely true because it's super racy. I was talking with Imre about this mess at some point, and

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove i915.enable_ppgtt override

== Series Details == Series: drm/i915: Remove i915.enable_ppgtt override URL : https://patchwork.freedesktop.org/series/50143/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Remove i915.enable_ppgtt override +drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning:

Re: [Intel-gfx] [PATCH 2/3] drm/i915: make the primary plane func structs const

On Mon, Sep 24, 2018 at 05:19:12PM -0700, Paulo Zanoni wrote: > Because we can, the places where we use them already expect const > structs. https://patchwork.freedesktop.org/series/44104/ already has the rest of the series covered. It didn't get pushed due to lack of drm-misc backmerge. I

Re: [Intel-gfx] [PATCH 1/3] drm/i915: DRM_FORMAT_C8 is not possible with Yf tiling

On Mon, Sep 24, 2018 at 05:19:11PM -0700, Paulo Zanoni wrote: > Function intel_framebuffer_init() checks for the possibilities during > framebuffer creation (addfb ioctl time). It is missing the fact that > the indexed format is not supported with Yf tiling. > > It is worth noticing that

[Intel-gfx] [PATCH v4] drm/i915: Remove i915.enable_ppgtt override

Now that we are confident in providing full-ppgtt where supported, remove the ability to override the context isolation. v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted. v3: s/USES/HAS/ to match usage and reject attempts to load the module on old GVT-g setups that do not

Re: [Intel-gfx] [PATCH 15/40] drm/i915: Priority boost for new clients

On Tue, 25 Sep 2018 10:26:57 +0200, Chris Wilson wrote: Quoting Chris Wilson (2018-09-25 09:01:06) Quoting Tvrtko Ursulin (2018-09-24 11:29:52) > > On 19/09/2018 20:55, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/i915_scheduler.h b/drivers/gpu/drm/i915/i915_scheduler.h > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2)

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2) URL : https://patchwork.freedesktop.org/series/50137/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4872 -> Patchwork_10275 = == Summary - SUCCESS == No regressions

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2)

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2) URL : https://patchwork.freedesktop.org/series/50137/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/selftests: Smoketest preemption

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2)

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Smoketest preemption (rev2) URL : https://patchwork.freedesktop.org/series/50137/ State : warning == Summary == $ dim checkpatch origin/drm-tip 74896f3f3355 drm/i915/selftests: Smoketest preemption -:92:

Re: [Intel-gfx] [PATCH 1/7] drm/i915/selftests: Smoketest preemption

On 25/09/2018 11:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-25 10:39:06) On 25/09/2018 09:31, Chris Wilson wrote: Very light stress test to bombard the submission backends with a large stream with requests of randomly assigned priorities. Preemption will be occasionally

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Apply correct ddi translation table for AML device

== Series Details == Series: drm/i915: Apply correct ddi translation table for AML device URL : https://patchwork.freedesktop.org/series/50139/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M]

Re: [Intel-gfx] [PATCH 1/7] drm/i915/selftests: Smoketest preemption

Quoting Tvrtko Ursulin (2018-09-25 10:39:06) > > On 25/09/2018 09:31, Chris Wilson wrote: > > Very light stress test to bombard the submission backends with a large > > stream with requests of randomly assigned priorities. Preemption will be > > occasionally requested, but never succeed! > > Why

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add new AML_ULX support list

== Series Details == Series: drm/i915: Add new AML_ULX support list URL : https://patchwork.freedesktop.org/series/50136/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4870_full -> Patchwork_10272_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH 2/7] drm/i915/execlists: Avoid kicking priority on the current context

On 25/09/2018 09:31, Chris Wilson wrote: If the request is currently on the HW (in port 0), then we do not need to kick the submission tasklet to evaluate whether we should be preempting itself in order to execute it again. In the case that was annoying me: execlists_schedule:

Re: [Intel-gfx] [PATCH 2/7] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v3.

Op 24-09-18 om 15:18 schreef Ville Syrjälä: > On Mon, Sep 24, 2018 at 02:35:13PM +0200, Maarten Lankhorst wrote: >> Op 21-09-18 om 21:31 schreef Ville Syrjälä: >>> On Fri, Sep 21, 2018 at 09:35:52PM +0300, Ville Syrjälä wrote: On Fri, Sep 21, 2018 at 07:39:40PM +0200, Maarten Lankhorst wrote:

Re: [Intel-gfx] [PATCH 1/1] initial panel_power_off_time should be 0

On Thu, 20 Sep 2018, ning.a.zh...@intel.com wrote: > From: Zhang Ning > > power on an eDP panel requests eDP panal fully powered off. > need to wait t11_t12 after LCDVCC is off. usually t12 is 500ms. > > code, intel_dp.c, func edp_panel_vdd_on, line 2010: > > if

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Combine multiple internal plists into the same i915_priolist bucket

On 25/09/2018 09:32, Chris Wilson wrote: As we are about to allow ourselves to slightly bump the user priority into a few different sublevels, packthose internal priority lists into the same i915_priolist to keep the rbtree compact and avoid having to allocate the default user priority even

Re: [Intel-gfx] [PATCH 1/7] drm/i915/selftests: Smoketest preemption

On 25/09/2018 09:31, Chris Wilson wrote: Very light stress test to bombard the submission backends with a large stream with requests of randomly assigned priorities. Preemption will be occasionally requested, but never succeed! Why won't it ever succeed? By design or because test is

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915/selftests: Smoketest preemption

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Smoketest preemption URL : https://patchwork.freedesktop.org/series/50137/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4870 -> Patchwork_10273 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH 16/40] drm/i915: Pull scheduling under standalone lock

Quoting Tvrtko Ursulin (2018-09-25 10:01:21) > > On 25/09/2018 09:19, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-09-24 12:19:39) > >> > >> On 19/09/2018 20:55, Chris Wilson wrote: > >>> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c > >>> b/drivers/gpu/drm/i915/i915_scheduler.c >

Re: [Intel-gfx] [PATCH v5] drm/i915: use for_each_pipe loop to assign crtc_mask

On Fri, 21 Sep 2018, Lucas De Marchi wrote: > On Wed, Sep 19, 2018 at 02:01:26PM +0530, Mahesh Kumar wrote: >> This cleanup patch makes changes to use for_each_pipe loop >> during bit-mask assignment of allowed crtc with encoder. >> >> changes: >> - use BIT(i) macro instead of (1 << i) (Chris)

Re: [Intel-gfx] [PATCH 16/40] drm/i915: Pull scheduling under standalone lock

On 25/09/2018 10:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-25 10:01:21) On 25/09/2018 09:19, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-24 12:19:39) On 19/09/2018 20:55, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/i915_scheduler.c

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915/selftests: Smoketest preemption

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Smoketest preemption URL : https://patchwork.freedesktop.org/series/50137/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/selftests: Smoketest preemption +./include/linux/slab.h:631:13:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915/selftests: Smoketest preemption

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Smoketest preemption URL : https://patchwork.freedesktop.org/series/50137/ State : warning == Summary == $ dim checkpatch origin/drm-tip 94c8bbdc1288 drm/i915/selftests: Smoketest preemption -:92:

Re: [Intel-gfx] [PATCH 15/40] drm/i915: Priority boost for new clients

On 25/09/2018 10:06, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-25 09:57:11) On 25/09/2018 09:26, Chris Wilson wrote: Quoting Chris Wilson (2018-09-25 09:01:06) Quoting Tvrtko Ursulin (2018-09-24 11:29:52) On 19/09/2018 20:55, Chris Wilson wrote: diff --git

Re: [Intel-gfx] [PATCH 15/40] drm/i915: Priority boost for new clients

Quoting Tvrtko Ursulin (2018-09-25 09:57:11) > > On 25/09/2018 09:26, Chris Wilson wrote: > > Quoting Chris Wilson (2018-09-25 09:01:06) > >> Quoting Tvrtko Ursulin (2018-09-24 11:29:52) > >>> > >>> On 19/09/2018 20:55, Chris Wilson wrote: > diff --git a/drivers/gpu/drm/i915/i915_scheduler.h

Re: [Intel-gfx] [PATCH 17/40] drm/i915: Priority boost for waiting clients

On 25/09/2018 10:00, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-24 12:29:45) On 19/09/2018 20:55, Chris Wilson wrote: +#define I915_PRIORITY_WAIT ((u8)BIT(1)) #define I915_PRIORITY_NEWCLIENT ((u8)BIT(0)) Put a comment here explaining the priority order is reversed in the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add new AML_ULX support list

== Series Details == Series: drm/i915: Add new AML_ULX support list URL : https://patchwork.freedesktop.org/series/50136/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4870 -> Patchwork_10272 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] [PATCH v2] drm/i915: Priority boost for waiting clients

Latency is in the eye of the beholder. In the case where a client stops and waits for the gpu, give that request chain a small priority boost (not so that it overtakes higher priority clients, to preserve the external ordering) so that ideally the wait completes earlier. v2: Tvrtko recommends to

Re: [Intel-gfx] [PATCH 16/40] drm/i915: Pull scheduling under standalone lock

On 25/09/2018 09:19, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-24 12:19:39) On 19/09/2018 20:55, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c new file mode 100644 index ..910ac7089596 --- /dev/null +++

Re: [Intel-gfx] [PATCH 17/40] drm/i915: Priority boost for waiting clients

Quoting Tvrtko Ursulin (2018-09-24 12:29:45) > > On 19/09/2018 20:55, Chris Wilson wrote: > > +#define I915_PRIORITY_WAIT ((u8)BIT(1)) > > #define I915_PRIORITY_NEWCLIENT ((u8)BIT(0)) > > Put a comment here explaining the priority order is reversed in the > internal range. > > With new

Re: [Intel-gfx] [PATCH 15/40] drm/i915: Priority boost for new clients

On 25/09/2018 09:26, Chris Wilson wrote: Quoting Chris Wilson (2018-09-25 09:01:06) Quoting Tvrtko Ursulin (2018-09-24 11:29:52) On 19/09/2018 20:55, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/i915_scheduler.h b/drivers/gpu/drm/i915/i915_scheduler.h index

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: delay hotplug scheduling

== Series Details == Series: drm/i915: delay hotplug scheduling URL : https://patchwork.freedesktop.org/series/50128/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4869_full -> Patchwork_10271_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH 12/40] drm/i915/execlists: Assert the queue is non-empty on unsubmitting

On 25/09/2018 08:41, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-24 10:07:11) On 19/09/2018 20:55, Chris Wilson wrote: In the sequence <0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset: engine_mask=1, ret=0, retry=0 <0>[ 531.960431] drv_self-48067

[Intel-gfx] [PATCH] drm/i915: Apply correct ddi translation table for AML device

Amber Lake used the same gen graphics as Kaby Lake. Kernel driver should configure KBL's DDI buffer setting for AML ULX as well. So far, driver would load DDI translation table that used for KBL H/S platform and apply it on AML devices. But AML is belong to ULX series. This change will lead

Re: [Intel-gfx] [PATCH 35/40] drm/i915: Fix I915_EXEC_RING_MASK

On 19/09/2018 20:55, Chris Wilson wrote: This was supposed to be a mask of all known rings, but it is being used by execbuffer to filter out invalid rings, and so is instead mapping high unused values onto valid rings. Instead of a mask of all known rings, we need it to be the mask of all

Re: [Intel-gfx] [PATCH 34/40] drm/i915: Allow contexts to share a single timeline across all engines

On 19/09/2018 20:55, Chris Wilson wrote: Previously, our view has been always to run the engines independently within a context. (Multiple engines happened before we had contexts and timelines, so they always operated independently and that behaviour persisted into contexts.) However, at the

Re: [Intel-gfx] [PATCH] drm/i915: delay hotplug scheduling

Quoting Jani Nikula (2018-09-25 08:18:36) > On some systems we get the hotplug irq on unplug before the DDC pins > have been disconnected, resulting in connector status remaining > connected. Since previous attempts at using hotplug live status before > DDC have failed, the only viable option is

[Intel-gfx] [PATCH 5/7] drm/i915: Priority boost for new clients

Taken from an idea used for FQ_CODEL, we give the first request of a new request flows a small priority boost. These flows are likely to correspond with short, interactive tasks and so be more latency sensitive than the longer free running queues. As soon as the client has more than one request in

[Intel-gfx] [PATCH 7/7] drm/i915: Priority boost for waiting clients

Latency is in the eye of the beholder. In the case where a client stops and waits for the gpu, give that request chain a small priority boost (not so that it overtakes higher priority clients, to preserve the external ordering) so that ideally the wait completes earlier. Testcase:

[Intel-gfx] [PATCH 4/7] drm/i915: Combine multiple internal plists into the same i915_priolist bucket

As we are about to allow ourselves to slightly bump the user priority into a few different sublevels, packthose internal priority lists into the same i915_priolist to keep the rbtree compact and avoid having to allocate the default user priority even after the internal bumping. The downside to

[Intel-gfx] [PATCH 3/7] drm/i915: Reserve some priority bits for internal use

In the next few patches, we will want to give a small priority boost to some requests/queues but not so much that we perturb the user controlled order. As such we will shift the user priority bits higher leaving ourselves a few low priority bits for our internal bumping. Signed-off-by: Chris

[Intel-gfx] [PATCH 6/7] drm/i915: Pull scheduling under standalone lock

Currently, the backend scheduling code abuses struct_mutex into order to have a global lock to manipulate a temporary list (without widespread allocation) and to protect against list modifications. This is an extraneous coupling to struct_mutex and further can not extend beyond the local device.

  1   2   >