== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev5)
URL : https://patchwork.freedesktop.org/series/73436/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16607_full
On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct
Hi Daniel,
On 2/19/20 11:21 AM, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> Aside: Another driver with a bit much devm_kzalloc, which should
> probably use drmm_kzalloc instead ...
>
> Signed-off-by: Daniel Vetter
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Benjamin
On Thu, Feb 20, 2020 at 11:20:05AM +, Emil Velikov wrote:
> On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > We have a nice little helper to compute a single LUT entry
> > for everything except the 8bpc legacy gamma mode. Let's
> > complete the set.
> >
On Wed, Feb 19, 2020 at 10:22:58PM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable
== Series Details ==
Series: drm/i915: make i915_debugfs_register return void.
URL : https://patchwork.freedesktop.org/series/73587/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16604_full
Summary
On Thu, 2020-02-20 at 15:11 +0200, stanislav.lisovs...@intel.com wrote:
> On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> > On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> > stanislav.lisovs...@intel.com> wrote:
> > > We might be willing to call intel_atomic_get_old_global_obj_state
> > > and
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode is extremely fat. Put it on diet.
>
> Some stats for the whole series:
>
> 64bit sizeof(struct drm_display_mode):
> 200 -> 136 bytes (-32%)
>
> 64bit bloat-o-meter -c drm.ko:
> add/remove: 1/0
On 20/02/2020 12:52, Chris Wilson wrote:
Quoting Matthew Auld (2020-02-20 12:47:28)
On 20/02/2020 07:50, Chris Wilson wrote:
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed
On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > We might be willing to call intel_atomic_get_old_global_obj_state
> > and intel_atomic_get_new_global_obj_state right away, however
> > those are not
On 07.02.2020 16:39, Alexey Budankov wrote:
>
> On 07.02.2020 14:38, Thomas Gleixner wrote:
>> Alexey Budankov writes:
>>> On 22.01.2020 17:25, Alexey Budankov wrote:
On 22.01.2020 17:07, Stephen Smalley wrote:
>> It keeps the implementation simple and readable. The implementation is
On 20/02/2020 12:36, Chris Wilson wrote:
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Reorganize drm_display_mode to eliminate all the holes.
> We'll put all the actual timings to the start of the
> struct and all the extra junk to the end.
>
> Gets the size down to 136 bytes on 64bit and 120 bytes on
Quoting Matthew Auld (2020-02-20 12:47:28)
> On 20/02/2020 07:50, Chris Wilson wrote:
> > While we know that the waiters cannot disappear as we walk our list
> > (only that they might be added), the same cannot be said for our
> > signalers as they may be completed by the HW and retired as we
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104.
v5.5.4: Failed to apply! Possible
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Instead of supporting ~2000km wide displayes let's limit ourselves
> to ~65m. That seems plenty big enough to me.
>
> Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
> 10*0xfff which fits into the 16
On 20/02/2020 07:50, Chris Wilson wrote:
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect
Adding ram's RB on patch1 and a new patch to fix DP HDCP Auth.
Anshuman Gupta (2):
drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg
drm/i915/hdcp: Return 0 on config_stream_type() +ve return
drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +-
1 file changed, 9 insertions(+),
As DP shim's config_stream_type returns size of message
to be written in case of success therefore on
config_stream_type success return a zero success
value in order to succeed the HDCP auth.
CC: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +++-
HDCP Repeater initializes seq_num_V to 0 at the beginning of
hdcp Session i.e. after AKE_init received, refer
HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20.
HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT
considers failure of authentication if the repeater provides a
non-zero value in seq_num_V
On Thu, 20 Feb 2020, Stanislav Lisovskiy wrote:
> We might be willing to call intel_atomic_get_old_global_obj_state
> and intel_atomic_get_new_global_obj_state right away, however
> those are not initializing global obj state as
> intel_atomic_get_global_obj_state does.
> Extracted initializing
On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR") was forcing the state compute too earlier
> causing errors because not everything was initialized, so here
> moving to
Hi Chris,
On Tuesday, February 11, 2020 5:44:59 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> > @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler,
NULL)
> > igt_subtest("invalid-null-pointer")
> >
We need to be extremely careful inside i915_request_await_start() as it
needs to walk the list of requests in the foreign timeline with very
little protection. As we hold our own timeline mutex, we can not nest
inside the signaler's timeline mutex, so all that remains is our RCU
protection.
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
---
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid
For Gen11+ platforms BSpec suggests disabling specific
QGV points separately, depending on bandwidth limitations
and current display configuration. Thus it required adding
a new PCode request for disabling QGV points and some
refactoring of already existing SAGV code.
Also had to refactor
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with
We might be willing to call intel_atomic_get_old_global_obj_state
and intel_atomic_get_new_global_obj_state right away, however
those are not initializing global obj state as
intel_atomic_get_global_obj_state does.
Extracted initializing part to separate function and now using this
also in
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_reg.h | 4
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2aafd2b07e4a..6d4240f260a9 100644
---
== Series Details ==
Series: drm/i915: remove the other slab_dependencies
URL : https://patchwork.freedesktop.org/series/73701/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7972 -> Patchwork_16643
Summary
---
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> -
== Series Details ==
Series: series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
URL : https://patchwork.freedesktop.org/series/73586/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16603_full
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The driver never sets mode->private_flags so copying
> it back and forth is entirely pointless. Stop doing it.
>
> Also drop private_flags from the tracepoint.
>
> Cc: Rob Clark
> Cc: Sean Paul
> Cc:
On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> We have a nice little helper to compute a single LUT entry
> for everything except the 8bpc legacy gamma mode. Let's
> complete the set.
>
At a later stage one could rename this & the 10bit one, moving them to
Hi Dave & Daniel -
Due to issues in s2idle in v5.6-rc2, I've gotten CI results on these
with two hack reverts on top, and I threw them out just before making
the pull request. I had to revert:
fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the
system")
e3728b50cd9b
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The drrs code dereferences mode->vrefresh via some really long chain
> of structures/pointers. Couldn't get coccinelle to see through all
> that so let's add some local variables to help it.
>
There's a limit to the
Quoting Matthew Auld (2020-02-20 10:57:07)
> The real one can be found in i915_scheduler.c.
>
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
You're not a fan of redundancy, I see :)
Oops,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing
The real one can be found in i915_scheduler.c.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Ville Syrjälä
Reviewed-by: Emil Velikov
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Let's just calculate the hsync rate on demand. No point in wasting
> space storing it and risking the cached value getting out of sync
> with reality.
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Wed, 19 Feb 2020, Andi Shyti wrote:
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create the 'gt/' directory in sysfs and move the power management
> related files.
>
> The new interfaces are:
>
> gt/gt_act_freq_mhz
> gt/gt_boost_freq_mhz
>
On Wed, 19 Feb 2020, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization feature,
I see I missed some commits in the actual tag, but I fixed this below.
drm-misc-fixes-2020-02-20:
drm-misc-fixes for v5.6-rc3:
- Fix dt binding for sunxi.
- Allow only 1 rotation argument, and allow 0 rotation in video cmdline.
- Small compiler warning fix for panfrost.
- Fix when using
> -Original Message-
> From: Intel-gfx On Behalf Of Manasi
> Navare
> Sent: Friday, February 14, 2020 5:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v3 3/3] drm/i915/dp: Add all tiled and port sync
> conns to
> modeset
>
> If one of the synced crtcs needs a
The draw-method-blt subtests require a working GPU, so create a subtest
group for the draw-methods, and skip the BLT group using
igt_require_gem() in its fixture.
Signed-off-by: Chris Wilson
---
tests/kms_draw_crc.c | 26 ++
1 file changed, 18 insertions(+), 8
If the blitter is not available, we cannot use it as a source for dirty
rectangles. We shall have to rely on the other engines to create GPU
dirty instead.
v2: Try using lots of subgroup+fixtures
Signed-off-by: Chris Wilson
---
tests/kms_frontbuffer_tracking.c | 57
We use the GPU to convert between tiling formats, indirectly via the
call to igt_create_pattern_fb. So before we try and execute commands on
the GPU, we should check that the GPU is available.
Signed-off-by: Chris Wilson
---
tests/kms_flip_tiling.c | 1 +
1 file changed, 1 insertion(+)
diff
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer
> -Original Message-
> From: Intel-gfx On Behalf Of Manasi
> Navare
> Sent: Friday, February 14, 2020 5:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v3 1/3] drm/i915: Introduce
> encoder->compute_config_late()
>
> From: Ville Syrjälä
>
> Add an optional
== Series Details ==
Series: series starting with [1/6] drm/i915/gt: Protect signaler walk with RCU
URL : https://patchwork.freedesktop.org/series/73691/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7970 -> Patchwork_16642
101 - 154 of 154 matches
Mail list logo
