== Series Details ==
Series: series starting with [1/5] drm/i915: fix guest virtual PCH detection on
non-PCH systems
URL : https://patchwork.freedesktop.org/series/43986/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4261 -> Patchwork_9153 =
== Summary - SUCCESS ==
No r
On Wed, 30 May 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The sprite code has a bunch of spaces where tabs should be used. Fix it
> up.
I guess the subject could be a little more specific; you aren't fixing
the whole driver after all. With that,
Reviewed-by: Jani Nikula
>
> Signed-
On Thu, 31 May 2018, "Xu, Colin" wrote:
> Hi Jani, any comments? Without correct PCH type, BXT in virtualization
> will fail to boot due to display initialization fail. If any more
> input required, please kindly let me know.
See [1] and please provide your Tested-by and/or Reviewed-by on the
rel
HAS_PCH_NOP() implies a PCH platform without south display, not generic
disabled display. Prefer num_pipes == 0 for PCH independent checks.
Cc: Ville Syrjala
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
I'm actually not sure about this. What should VLV, CHV, BXT and GLK do
in this branch i
Use intel_pch_type() also for mapping the no PCH case (PCH id 0) to
PCH_NONE to simplify code.
Also make sure that intel_pch_type() knows all the PCH ids returned by
intel_virt_detect_pch(). Loudly fail if this isn't the case; this
shouldn't happen anyway.
Cc: Colin Xu
Signed-off-by: Jani Nikula
Virtualized non-PCH systems such as Broxton or Geminilake should use
PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
specific case to indicate a PCH system without south display.
Reported-by: Colin Xu
Cc: Colin Xu
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c
HAS_PCH_NOP() implies a PCH platform without south display, not generic
disabled display. Prefer num_pipes == 0 for PCH independent checks.
Cc: Ville Syrjala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_i2c.c | 2 +-
2 files changed, 2 ins
Setting PCH type to PCH_NOP before checking whether we actually have a
PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
platforms. Fix this by using PCH_NOP only for platforms that actually
have a PCH.
Cc: Ville Syrjala
Signed-off-by: Jani Nikula
---
Should we log this with
On Thu, 31 May 2018, Souptick Joarder wrote:
> On Mon, May 21, 2018 at 4:48 PM, Souptick Joarder
> wrote:
>> On Thu, May 17, 2018 at 10:40 AM, Souptick Joarder
>> wrote:
>>> On Thu, May 17, 2018 at 12:48 AM, Chris Wilson
>>> wrote:
Quoting Souptick Joarder (2018-05-16 20:12:20)
> Us
On Mon, May 21, 2018 at 4:48 PM, Souptick Joarder wrote:
> On Thu, May 17, 2018 at 10:40 AM, Souptick Joarder
> wrote:
>> On Thu, May 17, 2018 at 12:48 AM, Chris Wilson
>> wrote:
>>> Quoting Souptick Joarder (2018-05-16 20:12:20)
Use new return type vm_fault_t for fault handler. For
Thank you.
Reviewed-By: Vidya Srinivas
> -Original Message-
> From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, May 22, 2018 12:26 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Maarten Lankhorst
>
> Subject: [PATCH 2/2] drm/i915: Configure SKL
Thank you.
Reviewed-By: Vidya Srinivas
> -Original Message-
> From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, May 22, 2018 12:26 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Maarten Lankhorst
>
> Subject: [PATCH 1/2] drm/i915: Remove bogus
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Colin Xu
>Sent: Wednesday, May 30, 2018 14:26
>To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update virtual PCH in single
>function
>
>
On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
> > This patchs adds the cec_notifier feature to the intel_hdmi part
> > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> > between each HDM
Setup a userptr object that only has a read-only mapping back to a file
store (memfd). Then attempt to write into that mapping using the GPU and
assert that those writes do not land (while also writing via a writable
userptr mapping into the same memfd to verify that the GPU is working!)
Signed-of
Exercise new API to probe that the userptr range is valid (backed by
struct pages and not pfn) or to populate the userptr upon creation (by
calling get_user_pages() on the range).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
tests/gem_userptr_blits.c | 140 ++
On Wed, May 30, 2018 at 10:00 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> intel_plane funcs can be cosnt. Make it so.
s/cosnt/const
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dr
On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of plane->fb (which we're going to deprecate for atomic drivers)
> we need to look at plane->state->fb. The maze of code leading to
> vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
On Wed, May 30, 2018 at 11:30:26AM -0700, Eric Anholt wrote:
> Ville Syrjälä writes:
>
> > On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote:
> >> Ville Syrjala writes:
> >>
> >> > From: Ville Syrjälä
> >> >
> >> > Up to now we've used the plane's modifier list as the primary
> >> >
Quoting Mika Kuoppala (2018-05-30 16:02:06)
> There is a problem with kbl up to rev E0 where a heavy
> memory traffic from adjacent engine(s) can cause an engine
> reset to fail. This traffic can be from normal memory accesses
> or it can be from heavy polling on a semaphore wait.
>
> To combat th
Ville Syrjala writes:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
> them.
>
> Cc: Eric Anholt
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Maarten Lankhorst
> Reviewed-by: Daniel Vetter
Reviewed-by: Eric Anholt
signature.asc
Description
Quoting Antonio Argenziano (2018-05-30 18:30:36)
>
>
> On 30/05/18 03:33, Chris Wilson wrote:
> > After hitting the SIGINT from execbuf, wait until the next timer signal
> > before trying again. This aligns the start of the ioctl to the timer,
> > hopefully maximising the amount of time we have f
Noralf Trønnes writes:
> These are needed for pl111 to use the generic fbdev emulation.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailma
== Series Details ==
Series: series starting with [1/2] drm/i915: Cancel reset preparations on
failed resets
URL : https://patchwork.freedesktop.org/series/43957/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4257_full -> Patchwork_9152_full =
== Summary - WARNING ==
Mi
Ville Syrjälä writes:
> On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote:
>> Ville Syrjala writes:
>>
>> > From: Ville Syrjälä
>> >
>> > Up to now we've used the plane's modifier list as the primary
>> > source of information for which modifiers are supported by a
>> > given plane.
Hi Dave,
One more fix that came in today. It's fixing a regression introduced during the
merge window, so it'd be nice to get it in.
drm-misc-fixes-2018-05-30:
dw-hdmi: Fix Oops regression from rc1 (Neil)
Cc: Neil Armstrong
Cheers, Sean
The following changes since commit 2bc5ff0bdc00d81d719d
== Series Details ==
Series: series starting with [1/2] drm/i915: Cancel reset preparations on
failed resets
URL : https://patchwork.freedesktop.org/series/43957/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9152 =
== Summary - WARNING ==
Minor unknow
Thanks Ville.
This series: Reviewed-by: Sinclair Yeh
On Fri, May 25, 2018 at 09:50:32PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Here are again the last (?) bits of eliminating the plane->fb/crtc
> usage for atomic drivers. I've pushed everything else (thanks to
> everyone who rev
On 30/05/18 03:33, Chris Wilson wrote:
Check twice for the signal interrupting the execbuf, because the real
world is messy.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106695
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio Argenziano
__
On 30/05/18 03:33, Chris Wilson wrote:
After hitting the SIGINT from execbuf, wait until the next timer signal
before trying again. This aligns the start of the ioctl to the timer,
hopefully maximising the amount of time we have for processing before
the next signal -- trying to prevent the cas
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev8)
URL : https://patchwork.freedesktop.org/series/42285/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4257_full -> Patchwork_9151_full =
== Summary - FAILURE ==
Serious unknown changes com
== Series Details ==
Series: series starting with [1/2] drm/i915: Cancel reset preparations on
failed resets
URL : https://patchwork.freedesktop.org/series/43957/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7d9f9247a4bb drm/i915: Cancel reset preparations on failed resets
9a
On 30/05/2018 16:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 16:27:02)
On 30/05/2018 15:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
On 30/05/2018 12:55, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse
From: Ville Syrjälä
Let's try to stick a common naming pattern in all the plane init funcs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 86 ++--
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
From: Ville Syrjälä
Use a more familiar naming pattern for our variables in the sprite plane
init function.
v2: Drop the redundant 'plane' from plane_formats and num_planes_formats
too
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 103 ++---
From: Ville Syrjälä
Untangle skl_plane_has_planar() into a more legible form.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/d
From: Ville Syrjälä
There's not much point in following the primary vs. sprite split
for the SKL+ universal plane init code. The only difference is
of our own doing in the form of the .check_plane(). Let's make
a small exception for that little detail and otherwise share
the same code to initiali
Quoting Tvrtko Ursulin (2018-05-30 17:56:20)
>
> On 29/05/2018 14:29, Chris Wilson wrote:
> > During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
> > disabling reset (gem_eio/suspend). This results in the device continuing
> > on without being reset, but since it has gone throu
From: Ville Syrjälä
Pull the common plane+plane_state allocation into a small helper.
Reduces the amount of boilerplate in the plane initialization
functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 44 ---
drivers/gpu/drm/i915/intel_
From: Ville Syrjälä
No point in having each caller of intel_create_plane_state() initialize
the scaler_id to -1. Instead just do it in intel_create_plane_state().
Previously we left scaler_id at 0 for pre-SKL platforms, but I can't
see how initializing it to -1 always would cause any harm.
Sign
From: Ville Syrjälä
Plane scaling is not supported with specific pixel formats. Disallow
plane scaling when such a format is used. Currently the only such
pixel format we expose is C8, but in case we add more in the future
let's make it easy to deal with them.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
All SKL+ universal planes support the same set of formats (with the
exception of NV12 which we don't expose yet). Make the format lists
for primary and sprites the same.
And make the format list const while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel
From: Ville Syrjälä
All CNL universal planes support horizontal mirroring. Currently
we expose the capability only for the primary plane. Expose it
for the overlay planes as well.
Cc: Joonas Lahtinen
Signed-off-by: Ville Syrjälä
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_spr
From: Ville Syrjälä
enum i9xx_plane_id namespace is not valid for any sprite plane,
so let's not even populate plane->i9xx_plane.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drive
From: Ville Syrjälä
The sprite code has a bunch of spaces where tabs should be used. Fix it
up.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b
From: Ville Syrjälä
We're currently not providing the possible_crtcs mask to
drm_universal_plane_init() for primary/cursor planes. While that does
work on account of drm_crtc_init_with_planes() filling those up
for us, it's inconsisten with what we're doing for sprite planes.
Let's just always p
From: Ville Syrjälä
intel_plane funcs can be cosnt. Make it so.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d4c9e249
From: Ville Syrjälä
Since NV12 more or less made it in I figured it's time to try and
land this plane init cleanup series once again.
Ville Syrjälä (13):
drm/i915: Constify intel_plane_funcs
drm/i915: Fix tabs vs. spaces
drm/i915: Populate possible_crtcs for primary/cursor planes
drm/i91
On Fri, May 25, 2018 at 12:27:40PM -0700, Fritz Koenig wrote:
> YUV planes need to be multiples of 2 to scan out. This was
> handled correctly for planes other than the primary in the
> intel_check_sprite_plane, where the code fixes up the plane
> and makes it compliant. Move this code into a locat
On 29/05/2018 14:29, Chris Wilson wrote:
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
Has some test been failing because
On Wed, 30 May 2018 15:53:34 +0200, Piotr Piorkowski
wrote:
At this moment we can define GuC logs sizes only using pages.
But GuC also allows use for this values expressed in megabytes.
Lets add support for define guc_log_size in megabytes when we
debug of GuC.
Signed-off-by: Piotr Piórkowsk
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev8)
URL : https://patchwork.freedesktop.org/series/42285/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9151 =
== Summary - SUCCESS ==
No regressions found.
External URL
On 30/05/18 03:33, Chris Wilson wrote:
As we measure the ring size, we never expect to find we can not submit
no batches at all. Assert against the unexpected.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
lib/i915/gem_ring.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/li
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev8)
URL : https://patchwork.freedesktop.org/series/42285/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Program RPCS for Broadwell
Okay!
Commit: drm/i915: Record the sseu configurati
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev8)
URL : https://patchwork.freedesktop.org/series/42285/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
11a6079c0062 drm/i915: Program RPCS for Broadwell
bc248ff938fc drm/i915: Record the sseu conf
On Wed, 30 May 2018 15:53:33 +0200, Piotr Piorkowski
wrote:
At this moment, we have defined GuC logs sizes in intel_guc_fwif.h, but
as these values are related directly to the GuC logs, and not to API of
GuC parameters, we should move these defines to intel_guc_log.h.
Signed-off-by: Piotr Pi
== Series Details ==
Series: series starting with [1/5] drm/i915: Remove stale asserts from
i915_gem_find_active_request()
URL : https://patchwork.freedesktop.org/series/43892/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9150 =
== Summary - FAILURE ==
Quoting Mika Kuoppala (2018-05-30 16:02:05)
> Our reset handling has a retry layer further up in the
> chain. As we have told the engine to prepare for reset,
> and failed it, make sure to remove that preparation so
> that the next attempted reset has a clean slate by triggering
> another full prep
== Series Details ==
Series: series starting with [1/7] drm/i915/guc: Don't store runtime GuC log
level in modparam
URL : https://patchwork.freedesktop.org/series/43952/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9149 =
== Summary - FAILURE ==
Serio
Quoting Tvrtko Ursulin (2018-05-30 16:27:02)
>
> On 30/05/2018 15:55, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
> >>
> >> On 30/05/2018 12:55, Chris Wilson wrote:
> >>> hrtimer is not reliable enough to assume fixed intervals, and so even
> >>> coarse accuracy (in the fa
== Series Details ==
Series: series starting with [1/7] drm/i915/guc: Don't store runtime GuC log
level in modparam
URL : https://patchwork.freedesktop.org/series/43952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ef254da06d89 drm/i915/guc: Don't store runtime GuC log level
On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and
On 30/05/2018 15:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
On 30/05/2018 12:55, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual
== Series Details ==
Series: drm/i915/pmu: Measure sampler intervals (rev2)
URL : https://patchwork.freedesktop.org/series/43795/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4257_full -> Patchwork_9148_full =
== Summary - FAILURE ==
Serious unknown changes coming with
On Wed, 30 May 2018 15:53:32 +0200, Piotr Piorkowski
wrote:
At the moment, the preparation of GUC_CTL_CTXINFO is disordered.
Lets move all GUC_CTL_CTXINFO related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: C
There is a problem with kbl up to rev E0 where a heavy
memory traffic from adjacent engine(s) can cause an engine
reset to fail. This traffic can be from normal memory accesses
or it can be from heavy polling on a semaphore wait.
To combat the normal traffic, we do our best to idle the adjacent
en
Our reset handling has a retry layer further up in the
chain. As we have told the engine to prepare for reset,
and failed it, make sure to remove that preparation so
that the next attempted reset has a clean slate by triggering
another full prepare cycle for the engines. Note that with
successful r
On Wed, 30 May 2018 15:53:31 +0200, Piotr Piorkowski
wrote:
At the moment, the preparation of GUC_CTL_LOG_PARAMS is disordered.
Additionally, in struct intel_guc_log we have an unnecessary field
'flags' which we use only to assign value to GuC parameter.
Lets move all GUC_CTL_LOG_PARAMS relat
On Wed, 30 May 2018 15:53:30 +0200, Piotr Piorkowski
wrote:
At the moment, the preparation of GUC_CTL_FEATURE is disordered.
Lets move all GUC_CTL_FEATURE related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Ch
On Wed, 30 May 2018 15:53:29 +0200, Piotr Piorkowski
wrote:
At the moment, the preparation of GUC_CTL_DEBUG is disordered.
Lets move all GUC_CTL_DEBUG related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris
Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
>
> On 30/05/2018 12:55, Chris Wilson wrote:
> > hrtimer is not reliable enough to assume fixed intervals, and so even
> > coarse accuracy (in the face of kasan and similar heavy debugging) we
> > need to measure the actual interval between sample.
> >
Hi,
On Wed, 30 May 2018 15:53:28 +0200, Piotr Piorkowski
wrote:
From: Piotr Piórkowski
Currently we are using modparam as placeholder for GuC log level.
Stop doing this and keep runtime GuC level in intel_guc_log struct.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał W
On 30/05/2018 12:55, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
While using a single timestamp to compute the interval does no
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
v2: Rename sysfs
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i9
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/d
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration pe
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may
Hi again,
Here are some updates following Chris & Michel's comments.
I folded the patch 6 added in v8 into patch 6 of this series.
Many thanks,
Chris Wilson (3):
drm/i915: Program RPCS for Broadwell
drm/i915: Record the sseu configuration per-context & engine
drm/i915: Expose RPCS (SSEU)
== Series Details ==
Series: drm/i915/pmu: Measure sampler intervals (rev2)
URL : https://patchwork.freedesktop.org/series/43795/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9148 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:
At this moment we can define GuC logs sizes only using pages.
But GuC also allows use for this values expressed in megabytes.
Lets add support for define guc_log_size in megabytes when we
debug of GuC.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
At this moment, we have defined GuC logs sizes in intel_guc_fwif.h, but
as these values are related directly to the GuC logs, and not to API of
GuC parameters, we should move these defines to intel_guc_log.h.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas L
At the moment, the preparation of GUC_CTL_CTXINFO is disordered.
Lets move all GUC_CTL_CTXINFO related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 30 ++
At the moment, the preparation of GUC_CTL_LOG_PARAMS is disordered.
Additionally, in struct intel_guc_log we have an unnecessary field
'flags' which we use only to assign value to GuC parameter.
Lets move all GUC_CTL_LOG_PARAMS related operations to one place,
and lets remove field 'flags' from str
At the moment, the preparation of GUC_CTL_FEATURE is disordered.
Lets move all GUC_CTL_FEATURE related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 22 +++
At the moment, the preparation of GUC_CTL_DEBUG is disordered.
Lets move all GUC_CTL_DEBUG related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 11 ++-
1
From: Piotr Piórkowski
Currently we are using modparam as placeholder for GuC log level.
Stop doing this and keep runtime GuC level in intel_guc_log struct.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i9
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the imp
== Series Details ==
Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev8)
URL : https://patchwork.freedesktop.org/series/36068/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4256 -> Patchwork_9147 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchw
Quoting Tvrtko Ursulin (2018-05-30 12:01:47)
>
> On 30/05/2018 11:55, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-30 11:43:16)
> >>
> >> On 29/05/2018 14:29, Chris Wilson wrote:
> >>> Since we use i915_gem_find_active_request() from inside
> >>> intel_engine_dump() and may call that at
Quoting Tvrtko Ursulin (2018-05-30 11:57:39)
>
> On 25/05/2018 18:45, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-25 18:31:35)
> >>
> >> On 25/05/2018 18:11, Chris Wilson wrote:
> >>> hrtimer is not reliable enough to assume fixed intervals, and so even
> >>> coarse accuracy (in the fa
On 30/05/2018 11:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 11:43:16)
On 29/05/2018 14:29, Chris Wilson wrote:
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the
== Series Details ==
Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev8)
URL : https://patchwork.freedesktop.org/series/36068/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
15891a2047c1 drm/i915: Introduce CRTC output format
22f13096d17e drm/i915: Add CRTC output format
On 25/05/2018 18:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-25 18:31:35)
On 25/05/2018 18:11, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual
Quoting Tvrtko Ursulin (2018-05-30 11:48:16)
>
> On 25/05/2018 16:14, Chris Wilson wrote:
> > We may not idle immediately after a hang, and indeed may send a pulse
> > down the pipeline periodically to become idle. Rather than make a flimsy
> > assumption about how long we need to sleep before the
Quoting Tvrtko Ursulin (2018-05-30 11:43:16)
>
> On 29/05/2018 14:29, Chris Wilson wrote:
> > Since we use i915_gem_find_active_request() from inside
> > intel_engine_dump() and may call that at any time, we do not guarantee
> > that the engine is paused nor that the signal kthreads and irq handle
On 25/05/2018 16:14, Chris Wilson wrote:
We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle;
On 29/05/2018 14:29, Chris Wilson wrote:
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb do
1 - 100 of 116 matches
Mail list logo
