This patch prevents division by zero htotal.
Signed-off-by: Tina Zhang
Cc: Adam Jackson
Cc: Dave Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_modes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index
On Tue, 2019-01-22 at 21:09 +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote:
> > On Tue, 22 Jan 2019, Ville Syrjälä
> > wrote:
> > > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote:
> > > > Avoid divide by zero warning on static analysis.
> >
== Series Details ==
Series: drm/i915: correct the pitch check for NV12 framebuffer (rev3)
URL : https://patchwork.freedesktop.org/series/53928/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468 -> Patchwork_12011
Summary
== Series Details ==
Series: drm/i915/icl: do a posting read after irq install
URL : https://patchwork.freedesktop.org/series/55598/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468_full -> Patchwork_12010_full
Summary
On 2019.01.21 11:51:41 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Signed-off-by: Jani Nikula
> ---
Looks good to me.
Acked-by: Zhenyu Wang
Will queue this up. Thanks!
>
== Series Details ==
Series: drm/i915/icl: do a posting read after irq install
URL : https://patchwork.freedesktop.org/series/55598/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468 -> Patchwork_12010
Summary
---
On 1/22/2019 6:32 PM, Daniele Ceraolo Spurio wrote:
When reading GEN11_GT_INTR_DWx closely after enabling the interrupts
in gen11_irq_postinstall, the returned value is garbage. This can
To clarify, this only happens (or at least I've only seen it) during
runtime_resume.
Daniele
cause
When reading GEN11_GT_INTR_DWx closely after enabling the interrupts
in gen11_irq_postinstall, the returned value is garbage. This can
cause other parts of the setup code (e.g. gen11_reset_one_iir) to
think that there are interrupts to be cleared when there are none.
The garbage value is only
On 1/21/2019 14:21, Chris Wilson wrote:
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so
Quoting John Harrison (2019-01-23 01:18:36)
> On 1/21/2019 14:20, Chris Wilson wrote:
> > @@ -479,8 +477,6 @@ static int __igt_reset_engine(struct drm_i915_private
> > *i915, bool active)
> > break;
> > }
> >
> > -
We may use HW semaphores to schedule nearly-ready work such that they
are already spinning on the GPU waiting for the completion on another
engine. However, we don't want for that spinning task to actually block
any real work should it be scheduled.
Signed-off-by: Chris Wilson
---
On 1/21/2019 14:20, Chris Wilson wrote:
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
---
== Series Details ==
Series: drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
URL : https://patchwork.freedesktop.org/series/55586/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465_full -> Patchwork_12009_full
On Fri, 2019-01-18 at 22:23 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be
> enabled when debugfs asks (rev2)
> URL : https://patchwork.freedesktop.org/series/55379/
> State : success
IGT series that this patches was
Quoting Chris Wilson (2019-01-21 22:21:16)
> We don't want to busywait on the GPU if we have other work to do. If we
> give non-busywaiting workloads higher (initial) priority than workloads
> that require a busywait, we will prioritise work that is ready to run
> immediately.
Fwiw, without
== Series Details ==
Series: drm/i915/selftests: Apply a subtest filter (rev3)
URL : https://patchwork.freedesktop.org/series/55576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465_full -> Patchwork_12008_full
Summary
On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote:
> A new field with the training pattern(TP) wakeup time for PSR2 was
These values are for PSR1, aren't they? Like you write in Patch 4/4,
the PSR2 control register does not have a bit to set anything other
than Tp2.
-DK
> added to
On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote:
> If the sink and source supports HBR3, TP4 should be used as link
> training pattern.
> For PSR2 there is no register to set and enable TP4 but according to
> eDP spec TP3 is still a training pattern acceptable for HBR3 panels.
>
Quoting John Harrison (2019-01-22 22:18:46)
> On 1/21/2019 14:20, Chris Wilson wrote:
> > In order to avoid preempting ourselves, we currently refuse to schedule
> > the tasklet if we reschedule an inflight context. However, this glosses
> > over a few issues such as what happens after a CS
Quoting John Harrison (2019-01-22 22:19:04)
> On 1/21/2019 14:20, Chris Wilson wrote:
> > In preparation for the next few commits, make resetting the GPU atomic.
> > Currently, we have prepared gen6+ for atomic resetting of individual
> > engines, but now there is a requirement to perform the
On 1/21/2019 14:20, Chris Wilson wrote:
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc
On 1/21/2019 14:20, Chris Wilson wrote:
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing
On 1/21/2019 14:20, Chris Wilson wrote:
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from
== Series Details ==
Series: drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
URL : https://patchwork.freedesktop.org/series/55586/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465 -> Patchwork_12009
Quoting Lucas De Marchi (2019-01-22 21:33:25)
> On Tue, Jan 22, 2019 at 6:32 AM Chris Wilson wrote:
> >
> > Quoting Lucas De Marchi (2019-01-22 05:12:24)
> > > Let's use a macro to make tables smaller and at the same time allow us
> > > to add fields that apply to all entries in future.
> > >
> >
On Tue, Jan 22, 2019 at 6:32 AM Chris Wilson wrote:
>
> Quoting Lucas De Marchi (2019-01-22 05:12:24)
> > Let's use a macro to make tables smaller and at the same time allow us
> > to add fields that apply to all entries in future.
> >
> > For the sake of readability, I'm calling an exception on
== Series Details ==
Series: drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
URL : https://patchwork.freedesktop.org/series/55586/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7cdae1834120 drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
On Gen 11 platform, to enable resolutions like 5K@120 where
the pixel clock is greater than pipe pixel rate, we need to split it across
2 pipes and enable it using DSC and big joiner. In order to support this
dual pipe single port mode, we need to link two crtcs involved in this
ganged mode.
This
== Series Details ==
Series: drm/i915/selftests: Apply a subtest filter (rev3)
URL : https://patchwork.freedesktop.org/series/55576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465 -> Patchwork_12008
Summary
---
On Tue, Jan 22, 2019 at 08:39:53PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
> NAK reply type
> URL : https://patchwork.freedesktop.org/series/55581/
> State : failure
>
> == Summary ==
>
> CI Bug Log -
This patch adds one test to evaluate suspend/resume operations using kms_flip.
Signed-off-by: Shayenne Moura
v2: Reduce test time to 10 (Daniel)
---
tests/kms_flip.c | 1 +
1 file changed, 1 insertion(+)
mode change 100644 => 100755 tests/kms_flip.c
diff --git a/tests/kms_flip.c
== Series Details ==
Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
NAK reply type
URL : https://patchwork.freedesktop.org/series/55581/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5465 -> Patchwork_12007
== Series Details ==
Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
NAK reply type
URL : https://patchwork.freedesktop.org/series/55581/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84875e8bb29f drm/dp/mst: Provide defines for ACK vs. NAK reply
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably
From: Ville Syrjälä
Make the code a bit easier to read by providing symbolic names
for the reply_type (ACK vs. NAK). Also clean up some brace stuff
while at it.
v2: s/DP_REPLY/DP_SIDEBAND_REPLY/ (DK)
Fix some checkpatch issues
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
From: Ville Syrjälä
Decode the NAK reply fields to make it easier to parse the logs.
v2: s/STR/DP_STR/ to avoid conflict with some header stuff (0day)
Use drm_dp_mst_req_type_str() more (DK)
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
---
== Series Details ==
Series: drm/i915/selftests: Apply a subtest filter (rev2)
URL : https://patchwork.freedesktop.org/series/55576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464 -> Patchwork_12006
Summary
---
== Series Details ==
Series: drm/i915: Avoid divide by zero
URL : https://patchwork.freedesktop.org/series/55560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464_full -> Patchwork_12005_full
Summary
---
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably
On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote:
> On Tue, 22 Jan 2019, Ville Syrjälä wrote:
> > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote:
> >> Avoid divide by zero warning on static analysis.
> >>
> >> Signed-off-by: Mika Kahola
> >> ---
> >>
Take an environment variable, SELFTESTS=foo,bar, and pass that along to
the kernel (as i915.st_filter=foo,bar) to provide fine grained test
selection. This can be either as an exact match to select only that
test, or to exclude only test. For example,
SELFTESTS=igt_vma_create,igt_vma_pin1
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably
On Tue, 22 Jan 2019, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote:
>> Avoid divide by zero warning on static analysis.
>>
>> Signed-off-by: Mika Kahola
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
On 22/01/2019 16:25, Joonas Lahtinen wrote:
Quoting Lionel Landwerlin (2019-01-16 17:36:22)
With the currently available parameters for the i915-perf stream,
there are still situations that are not well covered :
If an application opens the stream with polling disable or at very low
frequency
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> Now that our state comparison functions are pretty complete, we should
> enable fastset by default when a modeset can be avoided. Even if we're
> not completely certain about the inherited state, we can be certain
> after the first modeset that our
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> On lynxpoint the bios sometimes sets up the backlight using the CPU
> display, but the driver expects using the PWM PCH override register.
>
> Read the value from the CPU register, then convert it to the other
> units by converting from the old
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> Restore our saved values for backlight. This way even with fastset on
> S4 resume we will correctly restore the backlight to the active values.
>
> Changes since v1:
> - Call enable_backlight() when backlight.level is set. On suspend
>
On Tue, Jan 22, 2019 at 07:22:24PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To make vblank timestamps work better with the TV encoder let's
> > scale the pipe timings such that the relationship between the
> > TV
On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make vblank timestamps work better with the TV encoder let's
> scale the pipe timings such that the relationship between the
> TV active and TV blanking periods is mirrored in the
> corresponding pipe
== Series Details ==
Series: drm/i915: Use fb width to measure fb width instead of visible plane
width when verify NV12
URL : https://patchwork.freedesktop.org/series/8/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5463_full -> Patchwork_12004_full
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> According to our IOMMU folks there exists some desire to be able to assign
> the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> due to how the devices might be grouped in IOMMU groups. Even when you
> would
Hi Ville,
NV12 support for small src viewport sizes and rotation vs clipping scenarios
are added into IGT by JP.
Commit details are as follows.
commit 8614d5eb114a660c3bd7ff77eab8bed53424cd30
Author: Juha-Pekka Heikkila
Date: Fri Dec 21 15:42:33 2018 +0200
tests/kms_rotation_crc: add
Quoting Lionel Landwerlin (2019-01-16 17:36:22)
> With the currently available parameters for the i915-perf stream,
> there are still situations that are not well covered :
>
> If an application opens the stream with polling disable or at very low
> frequency and OA interrupt enabled, no data
On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote:
> Avoid divide by zero warning on static analysis.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
== Series Details ==
Series: drm/i915: Avoid divide by zero
URL : https://patchwork.freedesktop.org/series/55560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464 -> Patchwork_12005
Summary
---
**SUCCESS**
No
On 21/01/2019 22:21, Chris Wilson wrote:
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
Quoting Tvrtko Ursulin (2019-01-22 15:34:07)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > To allow requests to forgo a common execution timeline, one question we
> > need to be able to answer is "is this request running?". To track
> > whether a request has started on HW, we can emit a
On 21/01/2019 22:21, Chris Wilson wrote:
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its
Quoting Tvrtko Ursulin (2019-01-22 14:56:32)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > Now that we pin timelines around use, we have a clearly defined lifetime
> > and convenient points at which we can track only the active timelines.
> > This allows us to reduce the list iteration to only
On Mon, Nov 12, 2018 at 06:59:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the missing 1080p TV modes. On gen4 all of them work just fine,
> whereas on gen3 only the 30Hz mode actually works correctly.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
On Mon, Nov 12, 2018 at 06:59:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the silly reported_modes[] array. I suppse once upon a time
> this actually had something to do with modes we reported to userspace.
> Now it is just the placeholder for the mode we use for load
On 21/01/2019 22:21, Chris Wilson wrote:
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
On Mon, Nov 12, 2018 at 06:59:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current code insists on picking a new TV mode when
> switching between component and non-component cables.
> That's super annoying. Let's just keep the current TV
> mode unless the new cable type
Quoting Joerg Roedel (2019-01-22 13:01:09)
> Hi Daniel,
>
> On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> > Note that the string of platforms which have various issues with iommu
> > and igfx is very long, thus far we only disabled it where there's no
> > workaround to stop it
On Mon, Nov 12, 2018 at 06:59:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No point in storing the mode names in the array. drm_mode_set_name()
> will give us the same names without wasting space for these string
> constants.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre
On Mon, Nov 12, 2018 at 06:59:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rewrite the preferred mode selection to just check
> whether the TV modes is HD or SD. For SD TV modes we
> favor 480 line modes, for 720p we prefer 720 line modes,
> and for 1080i/p we prefer 1080 line
Quoting Lucas De Marchi (2019-01-22 05:12:25)
> Instead of considering we have defined entries for any index in the
> table, let's keep track of the ones we explicitly defined. This will
> allow Gen 11 to have it's new table defined in which we have holes of
> undefined entries.
>
> Repeated
== Series Details ==
Series: drm/i915: Use fb width to measure fb width instead of visible plane
width when verify NV12
URL : https://patchwork.freedesktop.org/series/8/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5463 -> Patchwork_12004
Quoting Lucas De Marchi (2019-01-22 05:12:26)
> Instead of checking the gen number every time we need to know the max
> number of entries, just save it into the table struct so we don't need
> extra branches throughout the code. This will be useful for Ice Lake
> that has 64 rather than 62 defined
Quoting Lucas De Marchi (2019-01-22 05:12:24)
> Let's use a macro to make tables smaller and at the same time allow us
> to add fields that apply to all entries in future.
>
> For the sake of readability, I'm calling an exception on 80 chars limit.
> Lines are aligned for easy comparison of the
Quoting Lucas De Marchi (2019-01-22 05:12:23)
> From: Tomasz Lis
>
> The MOCS tables are going to be very similar across platforms.
>
> To reduce the amount of copied code, this patch rips the common part and
> puts it into a definition valid for all gen9 platforms.
>
> v2: Made defines for
Quoting Lucas De Marchi (2019-01-22 05:12:21)
> Instead of initializing them to uncached, let's set them to PTE for
> kernel tracking. While at it do some minor adjustments to comments and
> coding style.
>
> Signed-off-by: Lucas De Marchi
I'm in favour. I do not think this contributes an ABI
Quoting Tvrtko Ursulin (2019-01-18 16:03:27)
>
> On 18/01/2019 14:00, Chris Wilson wrote:
> > Our goal is to remove struct_mutex and replace it with fine grained
> > locking. One of the thorny issues is our eviction logic for reclaiming
> > space for an execbuffer (or GTT mmaping, among a few
Please ignore this. This patch is all wrong.
/Juha-Pekka
On 22.1.2019 14.41, Juha-Pekka Heikkila wrote:
Using visible plane width for testing NV12 source suitability may fail
randomly when plane is clipped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Signed-off-by:
On Tue, 2019-01-22 at 15:07 +0200, Jani Nikula wrote:
> On Tue, 22 Jan 2019, Mika Kahola wrote:
> > Avoid divide by zero warning on static analysis.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
On Mon, Nov 12, 2018 at 06:59:51PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Just assign the margin values directly to xpos/ypos instead
> of first initializing to zero and then adding the values.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
>
On Mon, Nov 12, 2018 at 06:59:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 'component_only' is a bool. Initialize it like a bool.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 24
> 1 file changed,
On Tue, 22 Jan 2019, Mika Kahola wrote:
> Avoid divide by zero warning on static analysis.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
On Mon, Nov 12, 2018 at 06:59:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the oversampling factor as a number in the TV modes. We
> shall want to arithmetic with this which is easier if it's
> a number we can use directly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by:
Avoid divide by zero warning on static analysis.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8b63afa3a221..6a8e8b3f44c2 100644
---
On Mon, Nov 12, 2018 at 06:59:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The oversample clock is always supposed to be either 108 MHz
> or 148.5 MHz. Make it so.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
>
On Mon, Nov 12, 2018 at 06:59:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix the calculation of the vertical active period for interlaced
> TV modes.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 2 +-
>
On Tue, Nov 27, 2018 at 10:05:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On i965gm the hardware frame counter does not work when
> the TV encoder is active. So let's not try to consult
> the hardware frame counter in that case. Instead we'll
> fall back to the timestamp based
Quoting Mika Kuoppala (2019-01-22 12:39:08)
> Chris Wilson writes:
> > +static inline void
> > +intel_context_init(struct intel_context *ce,
> > +struct i915_gem_context *ctx,
> > +struct intel_engine_cs *engine)
> > +{
> > + ce->gem_context = ctx;
> > +}
> > +
Quoting Mika Kuoppala (2019-01-22 12:33:00)
> Chris Wilson writes:
>
> > This turns out to be quite useful if one happens to be debugging
> > semaphore deadlocks.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
> > 1 file changed, 11
Using visible plane width for testing NV12 source suitability may fail
randomly when plane is clipped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Chris Wilson writes:
> Prior to adding a third instance of intel_context_init() and extending
> the information stored therewithin, refactor out the common assignments.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 7 ++-
>
On Mon, 21 Jan 2019 at 22:22, Chris Wilson wrote:
>
> Before adding yet another copy of struct live_test and its handler,
> refactor the existing code into a common framework for live selftests.
> For many live selftests, we want to know if the GPU hung or otherwise
> misbehaved during the
Chris Wilson writes:
> This turns out to be quite useful if one happens to be debugging
> semaphore deadlocks.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git
On Mon, 21 Jan 2019 at 23:41, Chris Wilson wrote:
>
> Prior to adding a third instance of intel_context_init() and extending
> the information stored therewithin, refactor out the common assignments.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
On 21/01/2019 22:21, Chris Wilson wrote:
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> A new field with the training pattern(TP) wakeup time for PSR2 was
> added to VBT, so lets use it when available otherwise it will
> fallback to PSR1 wakeup time.
Same problems as with the two previous patches:
- The new field name is too
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> Newer VBTs and the PSR registers uses a enum to set the TPs wakeup
> time, so lets use this format to store wakeup times and avoid
> conversions every time that PSR is activated.
The VBT is a messy blob of data, and intel_bios.c in many places
On Mon, 21 Jan 2019 at 23:41, Chris Wilson wrote:
>
> Some tests (e.g. igt_vma_pin1) presume that we have a completely clean
> GGTT so that it can probe boundaries without fear that something is
> already allocated there. However, the mock device is starting to get
> complicated and following
Patch look ok to me.
On Thu, 2019-01-17 at 12:21 -0800, Lucas De Marchi wrote:
> Even if we don't have the correct clock and get a warning, we should
> not
> skip the return.
>
> Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
> Cc: Paulo Zanoni
> Cc: # v4.19+
Reviewed-by: Mika
On Mon, 21 Jan 2019 at 22:22, Chris Wilson wrote:
>
> During review of commit 71fc448c1aaf ("drm/i915/selftests: Make evict
> tolerant of foreign objects"), Matthew mentioned it would be better if
> we explicitly tracked the objects we created. We have an obj->st_link
> hook for this purpose, so
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> Recent update in spec made the field holding the TP2 and TP3 wakeup
> time for PSR also hold the TP4, so lets rename the variables to
> reflect that.
>
> BSpec: 20131
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
>
On 22/01/2019 11:12, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 10:47:11)
On 21/01/2019 22:21, Chris Wilson wrote:
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different
Quoting Tvrtko Ursulin (2019-01-22 10:47:11)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > If we restrict ourselves to only using a cacheline for each timeline's
> > HWSP (we could go smaller, but want to avoid needless polluting
> > cachelines on different engines between different contexts),
On 22/01/2019 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 09:31:31)
On 18/01/2019 14:00, Chris Wilson wrote:
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_user_extensions.h"
+
+int
1 - 100 of 136 matches
Mail list logo
