Quoting Martin Peres (2020-02-21 07:33:59)
> On 2020-02-20 19:41, Chris Wilson wrote:
> > Since we check before and then after each debugfs entry, we do not need
> > to check before each time as well. We will error out as soon as it does
> > fail, at all other times we know the system to be idle.
>
On 2020-02-21 10:21, Chris Wilson wrote:
> Quoting Martin Peres (2020-02-21 07:33:59)
>> On 2020-02-20 19:41, Chris Wilson wrote:
>>> Since we check before and then after each debugfs entry, we do not need
>>> to check before each time as well. We will error out as soon as it does
>>> fail, at all
On Tue, 18 Feb 2020, Wambui Karuga wrote:
> Manual conversion of instances of printk based drm logging macros to the
> struct drm_device based logging macros in i915/i915_perf.c.
> Also involves extraction of the struct drm_i915_private device from
> various intel types for use in the macros.
>
>
On Thu, 20 Feb 2020, "Souza, Jose" wrote:
> On Thu, 2020-02-20 at 09:41 +0530, Anshuman Gupta wrote:
>> On 2020-02-18 at 23:53:28 +0530, José Roberto de Souza wrote:
>> > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
>> > phase
>> > once to enable PSR") was forcing the state comp
I915_CONTEXT_PARAM_RINGSIZE specifies how large to create the command
ringbuffer for logical ring contects. This directly affects the number
of batches userspace can submit before blocking waiting for space.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources| 3 +
tests/i915/gem_ct
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc:
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Link: https://github.com/intel/compute-runtime/pull/261
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Steve Carbonari
Reviewed-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/Makefi
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
Cc: Steve Carbonari
---
drivers/gpu/drm/i915/i915_active.c | 42 ++
drivers/gpu/drm/i915/selftest
I915_CONTEXT_PARAM_RINGSIZE specifies how large to create the command
ringbuffer for logical ring contects. This directly affects the number
of batches userspace can submit before blocking waiting for space.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources| 3 +
tests/i915/gem_ct
Call cond_resched() between each freed object in case we have a really,
really long list, and we don't want to block normal processes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_
As we no longer stash anything inside i915_vma under the exclusive
protection of struct_mutex, we do not need to revoke the i915_vma
stashes before dropping struct_mutex to handle pagefaults. Knowing that
we must drop the struct_mutex while keeping the eb->vma around, means
that we are required to
With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_node() is
the only use
For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as our
primary means of
== Series Details ==
Series: drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx
URL : https://patchwork.freedesktop.org/series/73647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7965_full -> Patchwork_16623_full
On Thu, 20 Feb 2020, Randy Dunlap wrote:
> On 2/19/20 7:51 PM, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2020-02-19-19-51 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>>
>> mmotm-readme.txt says
>>
>> README for mm-of-the-moment:
>>
>> http://www.ozl
$(CC) with $(CFLAGS_GCOV) assumes the output filename with .gcno suffix
appended is writable. This is not the case when the output filename is
/dev/null:
HDRTEST drivers/gpu/drm/i915/display/intel_frontbuffer.h
/dev/null:1:0: error: cannot open /dev/null.gcno
HDRTEST drivers/gpu/drm/i915/displ
Currently unavoidable lockedp loop related to userptr MMU notifier
exists in the i915 driver. For that reason, attempts to set up a
mmap-offset (or mmap-gtt) mapping to a userptr object may be now
preventively rejected by the driver.
A test should exists which checks for that. Would a mapping at
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be stil
Submitted in series with PATCH 1/2 "lib/i915: Restrict mmap types to
GTT if no MMAP_OFFSET support", which I'm resubmitting without changes
as a dependency required for CI to be able to process PATCH 2/2.
Please focus on PATCH 2/2 "tests/gem_userptr_blits: Exercise mmap-offset
mapping to userptr"
Give the reset worker a kick before losing help when waiting for hang
recovery, as the CPU scheduler is a little unreliable.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 74 ++
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/dri
On Thu, Feb 20, 2020 at 04:05:17PM -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 initial
On Thu, 20 Feb 2020, Ville Syrjälä wrote:
> Looks like getting rid of private_flags is going to be pretty
> straightforward. I'll post patches for that once this first series
> lands.
Going all in on crtc state? I suppose migrating away from private_flags
could easily start in i915 before that. S
On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote:
> On Thu, 20 Feb 2020, Ville Syrjälä wrote:
> > Looks like getting rid of private_flags is going to be pretty
> > straightforward. I'll post patches for that once this first series
> > lands.
>
> Going all in on crtc state? I suppose mi
As there is a delay before we pin a vma, there is an opportunity for
another thread to have closed the vm and its vma (including us).
Check as soon as we acquire the vm->mutex and know the vm/vma is stable.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1291
Signed-off-by: Chris Wilson
-
As we no longer stash anything inside i915_vma under the exclusive
protection of struct_mutex, we do not need to revoke the i915_vma
stashes before dropping struct_mutex to handle pagefaults. Knowing that
we must drop the struct_mutex while keeping the eb->vma around, means
that we are required to
Op 21-02-2020 om 14:15 schreef Chris Wilson:
> As we no longer stash anything inside i915_vma under the exclusive
> protection of struct_mutex, we do not need to revoke the i915_vma
> stashes before dropping struct_mutex to handle pagefaults. Knowing that
> we must drop the struct_mutex while keepi
Quoting Maarten Lankhorst (2020-02-21 13:31:44)
> Op 21-02-2020 om 14:15 schreef Chris Wilson:
> > As we no longer stash anything inside i915_vma under the exclusive
> > protection of struct_mutex, we do not need to revoke the i915_vma
> > stashes before dropping struct_mutex to handle pagefaults.
Quoting Martin Peres (2020-02-21 08:28:16)
> On 2020-02-21 10:21, Chris Wilson wrote:
> > Quoting Martin Peres (2020-02-21 07:33:59)
> >> On 2020-02-20 19:41, Chris Wilson wrote:
> >>> Since we check before and then after each debugfs entry, we do not need
> >>> to check before each time as well. W
Since we check before and then after each debugfs entry, we do not need
to check before each time as well. We will error out as soon as it does
fail, at all other times we know the system to be idle.
No impact on runtime for glk (which apparently is one of the better
behaving systems).
v2: Assert
Hi Chris,
On Friday, February 21, 2020 10:43:21 AM CET Chris Wilson wrote:
> I915_CONTEXT_PARAM_RINGSIZE specifies how large to create the command
> ringbuffer for logical ring contects. This directly affects the number
s/contects/contexts/
> of batches userspace can submit before blocking waiti
On Thu, Feb 20, 2020 at 06:08:56PM +0200, Stanislav Lisovskiy wrote:
> There seems to be a bit of confusing redundancy in a way, how
> plane data rate/min cdclk are calculated.
> In fact both min cdclk, pixel rate and plane data rate are all
> part of the same formula as per BSpec.
>
> However cur
Quoting Janusz Krzysztofik (2020-02-21 13:57:26)
> Hi Chris,
>
> On Friday, February 21, 2020 10:43:21 AM CET Chris Wilson wrote:
> > +static unsigned int measure_inflight(int i915, unsigned int engine, int
> > timeout)
> > +{
> > + IGT_CORK_FENCE(cork);
> > + struct drm_i915_gem_exec_obj
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 ad
Quoting Janusz Krzysztofik (2020-02-21 11:17:00)
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> API. However, when run on an older vers
Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> Currently unavoidable lockedp loop related to userptr MMU notifier
> exists in the i915 driver. For that reason, attempts to set up a
> mmap-offset (or mmap-gtt) mapping to a userptr object may be now
> preventively rejected by the driver.
>
> A
== Series Details ==
Series: drm/i915: split i915_driver_modeset_probe() to pre/post irq install
URL : https://patchwork.freedesktop.org/series/73649/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966_full -> Patchwork_16624_full
==
On Fri, 2020-02-21 at 16:04 +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 06:08:56PM +0200, Stanislav Lisovskiy wrote:
> > There seems to be a bit of confusing redundancy in a way, how
> > plane data rate/min cdclk are calculated.
> > In fact both min cdclk, pixel rate and plane data rate a
dma_fence_get_rcu() is used to acquire a reference to under a dma-fence
under racey conditions -- a perfect recipe for a disaster. As we know
the caller may be handling stale memory, use kasan to confirm the
dma-fence, or rather its memory block, is valid before attempting to
acquire a reference. T
On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä
wrote:
>
> On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote:
> > On Thu, 20 Feb 2020, Ville Syrjälä wrote:
> > > Looks like getting rid of private_flags is going to be pretty
> > > straightforward. I'll post patches for that once this firs
Quoting Akeem G Abodunrin (2020-02-20 23:00:22)
> From: Mika Kuoppala
>
> This patch adds framework to submit an arbitrary batchbuffer on each
> context switch to clear residual state for render engine on Gen7/7.5
> devices.
>
> The idea of always emitting the context and vm setup around each re
On Sun, Dec 8, 2019 at 5:13 PM Chris Wilson wrote:
>
> If someone else acquires the i915_vma before we complete our wait and
> unbind it, we currently error out with -EBUSY. Use -EAGAIN instead so
> that if necessary the caller is prepared to try again.
>
> Signed-off-by: Chris Wilson
> Cc: Matth
Quoting Akeem G Abodunrin (2020-02-20 23:00:23)
> +static void emit_batch(struct i915_vma * const vma,
> + u32 *start,
> + const struct batch_vals *bv)
> +{
> + struct drm_i915_private *i915 = vma->vm->i915;
> + unsigned int desc_count = 64;
> +
On Fri, Feb 21, 2020 at 02:38:01PM +, Lisovskiy, Stanislav wrote:
> On Fri, 2020-02-21 at 16:04 +0200, Ville Syrjälä wrote:
> > On Thu, Feb 20, 2020 at 06:08:56PM +0200, Stanislav Lisovskiy wrote:
> > > There seems to be a bit of confusing redundancy in a way, how
> > > plane data rate/min cdcl
On Wed, Feb 19, 2020 at 9:35 PM Ville Syrjala
wrote:
> drm/exynos: Use mode->clock instead of reverse calculating it from the
> vrefresh
> drm: Nuke mode->vrefresh
I'm sure this is fine.
Acked-by: Linus Walleij
We need one: either clock or refresh settings, so it does make sense
to calcula
On Fri, Feb 21, 2020 at 3:38 PM Chris Wilson wrote:
> dma_fence_get_rcu() is used to acquire a reference to under a dma-fence
> under racey conditions -- a perfect recipe for a disaster. As we know
> the caller may be handling stale memory, use kasan to confirm the
> dma-fence, or rather its memor
Quoting Daniel Vetter (2020-02-21 15:17:24)
> On Fri, Feb 21, 2020 at 3:38 PM Chris Wilson wrote:
> > dma_fence_get_rcu() is used to acquire a reference to under a dma-fence
> > under racey conditions -- a perfect recipe for a disaster. As we know
> > the caller may be handling stale memory, use k
Quoting Chris Wilson (2020-02-21 15:23:38)
> Quoting Daniel Vetter (2020-02-21 15:17:24)
> > On Fri, Feb 21, 2020 at 3:38 PM Chris Wilson
> > wrote:
> > > dma_fence_get_rcu() is used to acquire a reference to under a dma-fence
> > > under racey conditions -- a perfect recipe for a disaster. As we
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate
== Series Details ==
Series: drm/i915/userptr: Activate MMU notifier only after pages are set
URL : https://patchwork.freedesktop.org/series/73652/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966_full -> Patchwork_16625_full
=
>From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915
in GuC/HuC paths") we stopped using HUC_STATUS error -ENODEV only
to indicate lack of HuC hardware and we started to use this error
also for all other cases when HuC was not in use or supported.
Fix that by relying again on HAS_GT_
Hi Chris,
Thanks for review.
On Friday, February 21, 2020 3:28:03 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > Currently unavoidable lockedp loop related to userptr MMU notifier
> > exists in the i915 driver. For that reason, attempts to set up a
> > mmap-off
Quoting Janusz Krzysztofik (2020-02-21 15:36:08)
> Hi Chris,
>
> Thanks for review.
>
> On Friday, February 21, 2020 3:28:03 PM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > > + /* set object pages in order to activate MMU notifier for it */
> > > +
On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote:
> > > On Thu, 20 Feb 2020, Ville Syrjälä wrote:
> > > > Looks like getting rid of private_flags is going to
From: Ville Syrjälä
One should use drm_connector_list_iter_end() rather than
drm_connector_list_iter_begin() to terminate the connector
iteration.
Cc: Manasi Navare
Cc: Uma Shankar
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1278
Fixes: e24bcd34c1dd ("drm/i915/dp: Add all tiled and
On Thu, 2020-02-20 at 12:55 -0800, Souza, Jose wrote:
> On Thu, 2020-02-20 at 12:39 +, Mun, Gwan-gyeong wrote:
> > 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 for
Quoting Ville Syrjala (2020-02-21 15:43:10)
> From: Ville Syrjälä
>
> One should use drm_connector_list_iter_end() rather than
> drm_connector_list_iter_begin() to terminate the connector
> iteration.
>
> Cc: Manasi Navare
> Cc: Uma Shankar
> Closes: https://gitlab.freedesktop.org/drm/intel/is
Quoting Chris Wilson (2020-02-21 15:46:22)
> Quoting Ville Syrjala (2020-02-21 15:43:10)
> > From: Ville Syrjälä
> >
> > One should use drm_connector_list_iter_end() rather than
> > drm_connector_list_iter_begin() to terminate the connector
> > iteration.
> >
> > Cc: Manasi Navare
> > Cc: Uma S
On 2/21/20 2:54 AM, Jani Nikula wrote:
> $(CC) with $(CFLAGS_GCOV) assumes the output filename with .gcno suffix
> appended is writable. This is not the case when the output filename is
> /dev/null:
>
> HDRTEST drivers/gpu/drm/i915/display/intel_frontbuffer.h
> /dev/null:1:0: error: cannot open
On Thu, Feb 20, 2020 at 10:55:18AM +, Emil Velikov wrote:
> 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
> > wit
On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote:
> > > > On Thu, 20 Feb 2020, Ville
Hi Ville.
On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the timings (apart from the clock) as u16. The uapi mode
> struct already uses u16 for everything so using something bigger
> internally doesn't really help us.
>
> Signed-off-by: Ville Syrj
On Wed, Feb 19, 2020 at 10:35:43PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> gma500 needs 4 bits (to store a pixel multiplier) in the
> mode->private_flags, i915 currently has three bits defined.
> No one else uses this. Reduce the size to u8.
>
> Signed-off-by: Ville Syrjälä
There
On Fri, 21 Feb 2020 at 12:19, Chris Wilson wrote:
>
> As there is a delay before we pin a vma, there is an opportunity for
> another thread to have closed the vm and its vma (including us).
> Check as soon as we acquire the vm->mutex and know the vm/vma is stable.
>
> Closes: https://gitlab.freede
On Fri, 21 Feb 2020 at 10:10, Chris Wilson wrote:
>
> Call cond_resched() between each freed object in case we have a really,
> really long list, and we don't want to block normal processes.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
== Series Details ==
Series: drm/i915: make dbuf configurations const
URL : https://patchwork.freedesktop.org/series/73659/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7966_full -> Patchwork_16627_full
Summary
---
On Fri, Feb 21, 2020 at 4:26 PM Chris Wilson wrote:
>
> Quoting Chris Wilson (2020-02-21 15:23:38)
> > Quoting Daniel Vetter (2020-02-21 15:17:24)
> > > On Fri, Feb 21, 2020 at 3:38 PM Chris Wilson
> > > wrote:
> > > > dma_fence_get_rcu() is used to acquire a reference to under a dma-fence
> > >
On Fri, 21 Feb 2020 at 16:04, Ville Syrjälä
wrote:
>
> On Thu, Feb 20, 2020 at 10:55:18AM +, Emil Velikov wrote:
> > 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
> > > spa
== Series Details ==
Series: drm/i915/gem: Break up long lists of object reclaim
URL : https://patchwork.freedesktop.org/series/73752/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7982 -> Patchwork_16655
Summary
---
On Thu, Feb 20, 2020 at 11:51:07PM +0100, Thomas Hellström (VMware) wrote:
> On 2/20/20 9:08 PM, Daniel Vetter wrote:
> > On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
> > > On 2/20/20 7:04 PM, Daniel Vetter wrote:
> > > > On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thoma
On Fri, Feb 21, 2020 at 06:09:04PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Fri, Feb 21, 2020
== Series Details ==
Series: series starting with [1/2] drm/i915/pmu: Avoid using globals for CPU
hotplug state
URL : https://patchwork.freedesktop.org/series/73663/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966_full -> Patchwork_16628_full
==
Hi Ville.
On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the timings (apart from the clock) as u16. The uapi mode
> struct already uses u16 for everything so using something bigger
> internally doesn't really help us.
>
> Signed-off-by: Ville Syrj
== Series Details ==
Series: series starting with [1/3] drm/i915: Drop inspection of execbuf flags
during evict
URL : https://patchwork.freedesktop.org/series/73753/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7982 -> Patchwork_16656
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_panel.c
The Thundersoft TST178 tablet uses a DSI panel with an external PWM
controller (as all DSI panels do). But unlike other DSI panels a duty-cycle
of 100% turns the backlight off and 0% sets it to maximum brightness.
I've checked the VBT and there is a BDB_LVDS_BACKLIGHT section, but
it does not set
== Series Details ==
Series: mmotm 2020-02-19-19-51 uploaded (gpu/drm/i915/ + HDRTEST)
URL : https://patchwork.freedesktop.org/series/73755/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
df38073c0873 mmotm 2020-02-19-19-51 uploaded (gpu/drm/i915/ + HDRTEST)
-:29: WARNING:COMMIT
Hi Dave, Daniel,
Here's a new round of drm-misc-next patches.
Thanks!
Maxime
drm-misc-next-2020-02-21:
drm-misc-next for 5.7:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- crtc: Drop get_crtc callback
- dp: Add support for DP1.4 EDID corruption test
- edid: Improve CEA detailed
On Fri, Feb 21, 2020 at 06:16:57PM +0100, Daniel Vetter wrote:
> On Fri, Feb 21, 2020 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> > > > On Fri, Feb 21, 2020 at 12:
== Series Details ==
Series: mmotm 2020-02-19-19-51 uploaded (gpu/drm/i915/ + HDRTEST)
URL : https://patchwork.freedesktop.org/series/73755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7982 -> Patchwork_16657
Summary
== Series Details ==
Series: drm/i915: fix header test with GCOV
URL : https://patchwork.freedesktop.org/series/73757/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
218e84549dfe drm/i915: fix header test with GCOV
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit de
On Fri, 2020-02-21 at 15:46 +, Mun, Gwan-gyeong wrote:
> On Thu, 2020-02-20 at 12:55 -0800, Souza, Jose wrote:
> > On Thu, 2020-02-20 at 12:39 +, Mun, Gwan-gyeong wrote:
> > > On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> > > > Commit 60c6a14b489b ("drm/i915/display: For
== Series Details ==
Series: drm: Put drm_display_mode on diet
URL : https://patchwork.freedesktop.org/series/73674/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7966_full -> Patchwork_16631_full
Summary
---
**FAILU
== Series Details ==
Series: drm/i915: fix header test with GCOV
URL : https://patchwork.freedesktop.org/series/73757/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7982 -> Patchwork_16658
Summary
---
**SUCCESS**
Record the LRC registers before/after a preemption event to ensure that
the first context sees nothing from the second client; at least in the
normal per-context register state.
References: https://gitlab.freedesktop.org/drm/intel/issues/1233
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
== Series Details ==
Series: Adding YUV444 packed format support for skl+ (rev3)
URL : https://patchwork.freedesktop.org/series/73020/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7966_full -> Patchwork_16632_full
Summary
On Wed, Feb 19, 2020 at 03:41:07PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 2:39 PM Laurent Pinchart
> wrote:
> >
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote:
> > > I also did a full review of all callers, and o
== Series Details ==
Series: drm/i915/selftests: Be a little more lenient for reset workers
URL : https://patchwork.freedesktop.org/series/73765/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7982 -> Patchwork_16659
Summary
The test throws a large number of objects at the GPU across many
batches. It only serves to try and assess the scaling impact, without
doing any conformance checking, nor analysing said impact of scaling.
The only effective coverage it gives us is on multi-engine reuse, which
any of the stress test
On 2/21/20 6:12 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 11:51:07PM +0100, Thomas Hellström (VMware) wrote:
On 2/20/20 9:08 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
On 2/20/20 7:04 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020
== Series Details ==
Series: drm/i915: Check that the vma hasn't been closed before we insert it
URL : https://patchwork.freedesktop.org/series/73768/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7982 -> Patchwork_16660
Su
On Fri, 2020-02-21 at 10:15 -0800, Souza, Jose wrote:
> On Fri, 2020-02-21 at 15:46 +, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-02-20 at 12:55 -0800, Souza, Jose wrote:
> > > On Thu, 2020-02-20 at 12:39 +, Mun, Gwan-gyeong wrote:
> > > > On Tue, 2020-02-18 at 12:39 -0800, José Roberto de So
On Thu, 2020-02-20 at 15:15 -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 the end of i915_drive
On Fri, 2020-02-21 at 20:04 +, Mun, Gwan-gyeong wrote:
> On Thu, 2020-02-20 at 15:15 -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 no
Hi Daniel.
In general I think I could follow the documentation, this is good.
If the overall design is the best possible I cannot say,
but looks sane to me.
I like the drmm_ naming as a counterpart to devm_, each handling
resources with different lifetimes.
What I miss in all of this is how do o
For two reasons:
- The driver core clears this already for us after we're unloaded in
__device_release_driver().
- It's way too late, the drm_device ->release callback might massively
outlive the underlying physical device, since a drm_device can't be
kept alive by open drm_file or well rea
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after a
Hi all,
Reading instructions still the same, first the doc patch at the end, then
the other stuff.
_Lots_ of small changes all over, a few fixes, mostly polish. I think this
should fix the "oops we've broken debugfs" issue that CI spotted on i915.
I think that was due to the totally busted pointe
I also did a full review of all callers, and only the xen driver
forgot to call drm_dev_put in the failure path. Fix that up too.
v2: I noticed that xen has a drm_driver.release hook, and uses
drm_dev_alloc(). We need to remove the kfree from
xen_drm_drv_release().
bochs also has a release hook,
With this we can drop the final kfree from the release function.
I also noticed that the unwind code is wrong, after drm_dev_init the
drm_device owns the v3d allocation, so the kfree(v3d) is a double-free.
Reorder the setup to fix this issue.
After a bit more prep in drivers and drm core v3d shou
1 - 100 of 200 matches
Mail list logo
