Re: [Intel-gfx] [PATCH 7/8] drm/i915/psr: Don't tell sink that main link will be active in PSR2

On Thu, 2018-09-20 at 13:43 -0700, José Roberto de Souza wrote: > For PSR2 we don't have the option to keep main link enabled while > PSR2 is active, so don't configure sink DPCD with a wrong value. Is this what the DP spec says or an Intel HW restriction? -DK > > Cc: Dhinakaran Pandiyan s >

[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 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 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:

[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 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 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 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 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 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 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

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 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] 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 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

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.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 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 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

[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 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 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.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: 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.BAT: failure for series starting with [v2,1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse()

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

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

Quoting Tvrtko Ursulin (2018-09-24 11:25:37) > > On 19/09/2018 20:55, 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

Re: [Intel-gfx] [PATCH 0/2] drm: Make i915 check for panel orient quirks on eDP and add one such quirk

Hi, On 09-09-18 15:34, Hans de Goede wrote: Hi All, This series fixes (works around) the gpd win 2's eDP panel being a portait mode panel being used in a landscape case (clamshell model). I plan to merge the i915 bit through dinq and the actual quirk through drm-misc. These 2 are related in

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check for panel orientation quirks on eDP panels

On Sun, 09 Sep 2018, Hans de Goede wrote: > So far we have only been calling > drm_connector_init_panel_orientation_property(), which checks for > panel orientation quirks in the drm_panel_orientation_quirks.c file, > for DSI panels as so far only devices with DSI panels have had panels > which

Re: [Intel-gfx] [PATCH 2/2] drm: panel-orientation-quirks: Add quirk for GPD win2

On Sun, 09 Sep 2018, Hans de Goede wrote: > GPD has done it again, make a nice device (good), use way too generic > DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly). > > Because of the too generic DMI strings this entry is also doing bios-date > matching, so the gpd_win2 data

[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 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 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/8] drm/i915/psr: Do not set MASK_DISP_REG_WRITE in ICL

On Thu, 20 Sep 2018, José Roberto de Souza wrote: > ICL spec states that this bit is now reserved. > > Spec: 7722 > > Cc: Dhinakaran Pandiyan > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/i915_reg.h | 4 ++-- > drivers/gpu/drm/i915/intel_psr.c | 17 +++-- >

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

Quoting Tvrtko Ursulin (2018-09-24 11:29:52) > > On 19/09/2018 20:55, Chris Wilson wrote: > > 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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Predictive governor to control eu/slice/subslice based on workload

On 25/09/2018 07:12, Navik, Ankit P wrote: Hi Tvrtko, Thank you for your valuable comments. We have gone through it. I'll be submitting revised patch-sets after incorporating all your review comments. You're welcome! Btw one more thing - you can suspend your timer when GPU goes idle and

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

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 7edfad0abfd7..93e43e263d8c 100644 > > >

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] ✓ 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 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 4/4] drm/i915: Predictive governor to control eu/slice/subslice based on workload

Hi Tvrtko, Thank you for your valuable comments. We have gone through it. I'll be submitting revised patch-sets after incorporating all your review comments. > On 21/09/2018 10:13, kedar.j.kara...@intel.com wrote: > > From: Praveen Diwakar > > > > High resoluton timer is used for this

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

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 527402571us :

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

According to patch "drm/i915/aml: Introducing Amber Lake platform" (e364672477a1). Add a new marco for AML ULX GT2 devices. Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Jose Roberto de Souza Signed-off-by: Lee, Shawn C --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ 1 file changed, 2 insertions(+) diff

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.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] ✗ 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 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 5/8] drm/i915/psr: Do not enable PSR2 if sink requires selective update X granularity

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 not supported by hardware, I think this warrants an explanation, what is not

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

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 to reduce the window for mistakes. Delay the

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

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: rq(18:211173).prio=0 -> 2 need_preempt:

[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.

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

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! v2: Include a second pattern with more frequent preemption Signed-off-by: Chris Wilson Cc: Michał Winiarski

[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

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 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 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

Re: [Intel-gfx] [PATCH 4/8] drm/i915/psr: Remove PSR2 TODO error handling

On Thu, 2018-09-20 at 13:43 -0700, José Roberto de Souza wrote: > We are already handling all PSR2 errors, so we can drop this TODO. Yes, we can remove it to thanks to all the work you have been doing. Reviewed-by: Dhinakaran Pandiyan > > Cc: Dhinakaran Pandiyan > Signed-off-by: José Roberto

[Intel-gfx] ✓ Fi.CI.BAT: 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 -> Patchwork_10271 = == Summary - SUCCESS == No regressions found. External URL:

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

On Mon, 24 Sep 2018, 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. > > BSpec: 21750 > > Cc: Maarten Lankhorst > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/intel_dp.c | 19

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 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 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.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 1/4] drm/i915: Get active pending request for given context

Hello Jani, On Tuesday 25 September 2018 01:34 PM, Jani Nikula wrote: On Fri, 21 Sep 2018, kedar.j.kara...@intel.com wrote: From: Praveen Diwakar This patch gives us the active pending request count which is yet to be submitted to the GPU Change-Id:

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

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

[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 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.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:

[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] [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 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] ✓ 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 8/8] drm/i915/psr: Remove alpm from i915_psr

On Thu, 2018-09-20 at 13:43 -0700, José Roberto de Souza wrote: > ALPM is a requirement and we don't need to keep it's cached, what > were done in commit 97c9de66ca80 > ("drm/i915/psr: Fix ALPM cap check for PSR2") but the alpm was not > removed from i915_psr.: You're right. Reviewed-by:

Re: [Intel-gfx] [PATCH 3/3] drm/i915: remove a copy of skl_plane_format_mod_supported()

On Mon, 2018-09-24 at 17:19 -0700, Paulo Zanoni wrote: > A little git-blame'ing suggests that both functions were added by > commit 714244e280de ("drm/i915: Add format modifiers for Intel"), as > skl_mod_supported() on intel_display.c and > skl_plane_format_mod_supported() on intel_sprite.c. At

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: delay hotplug scheduling

== Series Details == Series: drm/i915: delay hotplug scheduling URL : https://patchwork.freedesktop.org/series/50128/ State : warning == Summary == $ dim checkpatch origin/drm-tip 060d2552451c drm/i915: delay hotplug scheduling -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit

Re: [Intel-gfx] [PATCH 1/2] drm: Do not call drm_dp_cec_set_edid() while registering DP connectors

On 09/25/2018 03:16 AM, José Roberto de Souza wrote: drm_dp_cec_register_connector() is called when registering each DP connector in DRM, while sounds a good idea register CEC adapters as earlier as possible, it causes some driver initialization delay trying to do DPCD transactions in

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Get active pending request for given context

On Fri, 21 Sep 2018, kedar.j.kara...@intel.com wrote: > From: Praveen Diwakar > > This patch gives us the active pending request count which is yet > to be submitted to the GPU > > Change-Id: I10c2828ad0f1a0b7af147835737134e07a2d5b6d Please remove these. > Signed-off-by: Praveen Diwakar >

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

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 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 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 +++

[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:

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 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/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ä

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] 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 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/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 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

[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

  1   2   >