== Series Details ==
Series: drm: Replace zero-length array with flexible-array member
URL : https://patchwork.freedesktop.org/series/73916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8008_full -> Patchwork_16708_full
Su
On Thu, 27 Feb 2020, "Laxminarayan Bharadiya, Pankaj"
wrote:
> Hi Chris,
>
>> -Original Message-
>> From: Chris Wilson
>> Sent: 25 February 2020 19:32
>> To: David Airlie ; Joonas Lahtinen
>> ; Laxminarayan Bharadiya, Pankaj
>> ; Vivi, Rodrigo
>> ; dan...@ffwll.ch; dri-de...@lists.free
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. However
Wait for the last request (and so waits for all context updates) when
disabling OA. This prevents a rather bizarre error seen on Skylake
where the context is subsequently corrupted. Let's play safe and assume
it may impact all.
Reported-by: Lionel Landwerlin
Signed-off-by: Chris Wilson
Cc: Lione
Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.
v2ish: Use the ce->pin_count to close the execbuf gap.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241
Signed-off-by: Chris Wilson
Cc:
The engine->kernel_context is a special case for request emission. Since
it is used as the barrier within the engine's wakeref, we must acquire the
wakeref before submitting a request to the kernel_context.
Reported-by: Lionel Landwerlin
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
dr
Check that we can recover if the LRC is totally corrupted. Based on a
very simple theory that anything that can be adjusted via the context
(i.e. on behalf of the user), should be under the purview of the
per-engine-reset.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/dr
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilso
An odd and highly unlikely path caught us out. On delayed submission
(due to an asynchronous reset handler), we poked the priority_hint and
kicked the tasklet. However, we had already marked the device as wedged
and swapped out the tasklet for a no-op. The result was that we never
cleared the prior
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
drivers/gpu/drm/i915/sel
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
If a context is banned even before we submit our first request to it,
report the failure before we attempt to allocate any resources for the
context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
1 file changed, 5 insertions(+)
dif
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
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/
As setup takes a long time, the user may close the context during the
construction of the execbuf. In order to make sure we correctly track
all outstanding work with non-persistent contexts, we need to serialise
the submission with the context closure and mop up any leaks.
Signed-off-by: Chris Wil
Inside the general i915_oa_init_reg_state() we avoid using the
perf->mutex. However, we rely on perf->exclusive_stream being valid to
access at that point, and for that we have to control the race with
disabling perf. This relies on the disabling being a heavy barrier that
inspects all active conte
Attaching to the i915_active barrier is a two stage process, and a flush
is only effective when the barrier is activation. Thus it is possible
for us to see a barrier, and attempt to flush, only for our flush to
have no effect. As such, before attempting to activate signaling on the
fence we need t
Still chasing the mystery of the stray idle flush, let's ensure that the
heartbeat does not run at the same time as our test and confuse us.
References: https://gitlab.freedesktop.org/drm/intel/issues/541
Signed-off-by: Chris Wilson
---
.../drm/i915/gt/selftest_engine_heartbeat.c | 30
As we require a context switch to ensure that the current context is
switched out and saved to memory, perform an explicit switch to the
kernel context and wait for it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 37 +++---
1 file changed, 28 inse
We only use sentinel requests for "preempt-to-idle" passes, so assert
that they are the only request in a new submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_l
To prevent the context from proceeding past the end of the request as we
unwind, we embed a semaphore into the footer of each request. (If the
context were to skip past the end of the request as we perform the
preemption, next time we reload the context it's RING_HEAD would be past
the RING_TAIL an
Pull the final atomic_dec of vm->open (marking the vm as closed)
underneath the same vm->mutex as used to close it. This is required to
correctly serialise with attempting to reuse the vma as the vm is closed
by a second thread.
References: 00de702c6c6f ("drm/i915: Check that the vma hasn't been c
== Series Details ==
Series: series starting with [01/20] drm/i915: Skip barriers inside waits
URL : https://patchwork.freedesktop.org/series/73999/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7e51c69c481c drm/i915: Skip barriers inside waits
c38fa802dbde drm/i915/perf: Mark
Am 26.02.20 um 17:32 schrieb Daniel Vetter:
On Tue, Feb 25, 2020 at 6:16 PM Daniel Vetter wrote:
On Mon, Feb 24, 2020 at 07:46:59PM +0100, Christian König wrote:
Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware):
On 2/23/20 4:45 PM, Christian König wrote:
Am 21.02.20 um 18:12 schrieb Da
== Series Details ==
Series: drm/i915/selftests: Add request throughput measurement to perf
URL : https://patchwork.freedesktop.org/series/73930/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8008_full -> Patchwork_16712_full
===
On Thu, Feb 27, 2020 at 10:20 AM Christian König
wrote:
> Am 26.02.20 um 17:32 schrieb Daniel Vetter:
> > On Tue, Feb 25, 2020 at 6:16 PM Daniel Vetter wrote:
> >> On Mon, Feb 24, 2020 at 07:46:59PM +0100, Christian König wrote:
> >>> Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware):
>
On 2020.02.26 13:58:32 +0200, Jani Nikula wrote:
> On Wed, 26 Feb 2020, Zhenyu Wang wrote:
> > Hi,
> >
> > Here's gvt-next pull. Mostly for cleanup and kvmgt specific struct
> > has been moved to its own module, also enable VFIO edid for all platform
> > including CML. Pls see details below.
>
>
== Series Details ==
Series: series starting with [01/20] drm/i915: Skip barriers inside waits
URL : https://patchwork.freedesktop.org/series/73999/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8013 -> Patchwork_16729
Summ
Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.
v2ish: Use the ce->pin_count to close the execbuf gap.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241
Signed-off-by: Chris Wilson
Cc:
== Series Details ==
Series: drm/i915/display: conversion to drm_device based logging macros (rev4)
URL : https://patchwork.freedesktop.org/series/72760/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c1ef2220a44e drm/i915/dsb: convert to drm_device based logging macros.
86a7f80
== Series Details ==
Series: series starting with [01/17] drm/i915/gt: Reset queue_priority_hint
after wedging
URL : https://patchwork.freedesktop.org/series/73947/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8008_full -> Patchwork_16714_full
===
Daniele Ceraolo Spurio writes:
> On TGL, bits 2-4 in the GGTT PTE are not ignored anymore and are
> instead used for some extra VT-d capabilities. We don't (yet?) have
> support for those capabilities, but, given that we shared the pte_encode
> function betweed GGTT and PPGTT, we still set those
== Series Details ==
Series: drm/i915/display: conversion to drm_device based logging macros (rev4)
URL : https://patchwork.freedesktop.org/series/72760/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8013 -> Patchwork_16730
Quoting Mika Kuoppala (2020-02-27 10:51:46)
> Daniele Ceraolo Spurio writes:
> > static void gen8_set_pte(void __iomem *addr, gen8_pte_t pte)
> > {
> > writeq(pte, addr);
> > @@ -172,7 +179,7 @@ static void gen8_ggtt_insert_page(struct
> > i915_address_space *vm,
> > gen8_pte_t __io
Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.
v2ish: Use the ce->pin_count to close the execbuf gap.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241
Signed-off-by: Chris Wilson
Cc:
Wait for the last request (and so waits for all context updates) when
disabling OA. This prevents a rather bizarre error seen on Skylake
where the context is subsequently corrupted. Let's play safe and assume
it may impact all.
Reported-by: Lionel Landwerlin
Signed-off-by: Chris Wilson
Cc: Lione
== Series Details ==
Series: drm/i915: Set up PIPE_MISC truncate bit on tgl+
URL : https://patchwork.freedesktop.org/series/73960/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8010 -> Patchwork_16719
Summary
---
**S
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
Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of i915_debugfs_register() and
intel_display_debugfs_register() and have both functions return void.
Signed-of
We still need to wait for the initial OA configuration to happen
before we enable OA report writes to the OA buffer.
Signed-off-by: Lionel Landwerlin
Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command
stream")
---
drivers/gpu/drm/i915/i915_perf.c | 49 +
On Thu, 27 Feb 2020, Wambui Karuga wrote:
> Since 987d65d01356 (drm: debugfs: make
> drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
> fails and should return void. Therefore, remove its use as the
> return value of i915_debugfs_register() and
> intel_display_debugfs_regis
On Fri, 21 Feb 2020, 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_driver_modeset_pro
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
Hi Dave, Daniel,
Here's this week drm-misc-next PR.
Thank!
Maxime
drm-misc-next-2020-02-27:
drm-misc-next for $kernel-version:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- bridge: huge rework to get rid of omap_dss custom display drivers
Driver Changes:
- hisilicon: some fixes
On Thu, Feb 27, 2020 at 03:20:10PM +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
Turn current intel_modeset_init() to a pre-gem init function, and add a
new intel_modeset_init() function and move all post-gem modeset init
there, in the correct layer. Again, apart from possible failure paths,
no functional changes.
v2: Rebased
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä # v
With the intel_display_* probe/remove functions clarified, we can
continue with moving more related calls to the right layer:
- drm_vblank_init()
- intel_bios_init() and intel_bios_driver_remove()
- intel_vga_register() and intel_vga_unregister()
- intel_csr_ucode_init() and intel_csr_ucode_fini()
The i915_driver_modeset_*() functions have become irrelevant, and the
extra layer can be removed.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 76 +
1 file changed, 19 insertions(+), 57 deletions(-
On Thu, 2020-02-27 at 15:47 +0200, Ville Syrjälä wrote:
> On Thu, Feb 27, 2020 at 03:20:10PM +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
Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to
intel_vgpu_detect() to match other function naming, un-inline
intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and
intel_vgpu_has_huge_gtt() to reduce header interdependencies.
The i915_vgpu.[ch] filename and intel_vgpu_ prefix di
Nobody else uses it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/intel_gvt.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a306ebe44a08..e57d712
i915_drv.c is the only caller.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 254144678e19..9803e84
On 2/26/2020 6:02 AM, Michal Wajdeczko wrote:
On 25.02.2020 08:49, Ye, Tony wrote:
On 2/21/2020 11:32 PM, Michal Wajdeczko wrote:
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 h
Finish the job started in d28ae3b28187 ("drm/i915: split out
intel_dram.[ch] from i915_drv.c") by moving struct dram_dimm_info and
dram_channel_info inside intel_dram.c, the only user of the structs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/dr
== Series Details ==
Series: series starting with [01/20] drm/i915: Skip barriers inside waits (rev4)
URL : https://patchwork.freedesktop.org/series/73999/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ea6f01e92c61 drm/i915: Skip barriers inside waits
b03376b455cc drm/i915/perf
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: Refactor Gen11+ SAGV support (rev6)
URL : https://patchwork.freedesktop.org/series/73856/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a72659eb4666 drm/i915: Start passing latency as parameter
81ddfe1ca471 drm/i915: Introduce skl_plane_wm_level acc
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev6)
URL : https://patchwork.freedesktop.org/series/73856/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Introduce skl_pl
== Series Details ==
Series: series starting with [01/20] drm/i915: Skip barriers inside waits (rev4)
URL : https://patchwork.freedesktop.org/series/73999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8018 -> Patchwork_16731
===
On Mon, Feb 24, 2020 at 05:32:34PM +0200, Stanislav Lisovskiy wrote:
> 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.
>
> Curr
On Mon, Feb 24, 2020 at 05:32:35PM +0200, Stanislav Lisovskiy wrote:
> Add correspondent helpers to be able to get old/new bandwidth
> global state object.
>
> v2: - Fixed typo in function call
> v3: - Changed new functions naming to use convention proposed
> by Jani Nikula, i.e intel_bw_* i
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev6)
URL : https://patchwork.freedesktop.org/series/73856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8018 -> Patchwork_16732
Summary
---
**SUCCESS**
Having an array pipe_crc[I915_MAX_PIPES] in struct drm_i915_private
should be an obvious clue this should be located in struct intel_crtc
instead. Make it so.
As a side-effect, fix some errors in indexing pipe_crc with both pipe
and crtc index. And, of course, reduce the size of i915_drv.h.
Cc: A
On Tue, Feb 25, 2020 at 04:57:33PM +0200, Stanislav Lisovskiy wrote:
> The reasoning behind this is such that current dependencies
> in the code are rather implicit in a sense, we have to constantly
> check a bunch of different bits like state->modeset,
> state->active_pipe_changes, which sometimes
On Tue, Feb 25, 2020 at 05:00:43PM +0200, Stanislav Lisovskiy wrote:
> 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)
On Thu, Feb 27, 2020 at 06:12:53PM +0200, Jani Nikula wrote:
> Having an array pipe_crc[I915_MAX_PIPES] in struct drm_i915_private
> should be an obvious clue this should be located in struct intel_crtc
> instead. Make it so.
>
> As a side-effect, fix some errors in indexing pipe_crc with both pip
On Mon, Feb 24, 2020 at 05:32:33PM +0200, Stanislav Lisovskiy wrote:
> 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 mat
== Series Details ==
Series: drm/i915/perf: reintroduce wait on OA configuration completion
URL : https://patchwork.freedesktop.org/series/74014/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9c67fa7e5fe9 drm/i915/perf: reintroduce wait on OA configuration completion
-:28: CHEC
On Thu, Feb 27, 2020 at 04:53:59PM +0200, Jani Nikula wrote:
> Finish the job started in d28ae3b28187 ("drm/i915: split out
> intel_dram.[ch] from i915_drv.c") by moving struct dram_dimm_info and
> dram_channel_info inside intel_dram.c, the only user of the structs.
>
> Signed-off-by: Jani Nikula
From: Ville Syrjälä
The dbuf state will be where we collect all the inter-pipe dbuf
allocation stuff. Start by moving the actual per-pipe ddb entries
there.
v2: Rebase
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 28 +++-
== Series Details ==
Series: drm/i915/perf: reintroduce wait on OA configuration completion
URL : https://patchwork.freedesktop.org/series/74014/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8019 -> Patchwork_16733
Summary
On Thu, 27 Feb 2020, Ross Zwisler wrote:
> On Thu, Feb 27, 2020 at 03:18:26PM +0200, Jani Nikula wrote:
>> On Fri, 21 Feb 2020, 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 earli
== Series Details ==
Series: series starting with [1/3] drm/i915: split intel_modeset_init()
pre/post gem init
URL : https://patchwork.freedesktop.org/series/74021/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1f41c9f2b641 drm/i915: split intel_modeset_init() pre/post gem ini
Keep reducing i915_drv.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_ioc32.c | 6 --
drivers/gpu/drm/i915/i915_ioc32.h | 17 +
4 files changed, 23 insertions(+), 8 deletio
Shrink i915_drv.h a bit by moving watermark structs where they are
needed.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 16
drivers/gpu/drm/i915/i915_drv.h | 40 ---
drivers/gpu/drm/i915/intel_pm.c | 24 ++
Unused since commit f97108d1d0fa ("drm/i915: add dynamic performance
control support for Ironlake"). That's a little over ten years. Good
riddance.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
Quoting Lionel Landwerlin (2020-02-27 12:43:56)
> We still need to wait for the initial OA configuration to happen
> before we enable OA report writes to the OA buffer.
I can confirm this fixes the hang Lionel reported on Skylake [still odd
that we can only get this to be an issue on skl]. However
On 2020-02-27 at 09:04:03 +0200, Jani Nikula wrote:
> On Thu, 27 Feb 2020, Anshuman Gupta wrote:
> > Fix kbuild test robot build error for below commit
> > .
>
> The proper format to reference other commits is
>
> d54c1a513c48 ("drm/i915: Fix broken transcoder err state")
>
> If you put t
== Series Details ==
Series: series starting with [1/3] drm/i915: split intel_modeset_init()
pre/post gem init
URL : https://patchwork.freedesktop.org/series/74021/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8019 -> Patchwork_16734
=
On Sat, Feb 22, 2020 at 03:16:24PM +, Russell King - ARM Linux admin wrote:
> On Fri, Feb 21, 2020 at 10:02:46PM +0100, Daniel Vetter wrote:
> > These are the leftover drivers that didn't have a ->release hook that
> > needed to be updated.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: "James
== Series Details ==
Series: drm/i915/selftests: Disable heartbeat around manual pulse tests
URL : https://patchwork.freedesktop.org/series/73958/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8010_full -> Patchwork_16718_full
==
On Wed, Feb 26, 2020 at 10:34:54PM +0200, Imre Deak wrote:
> Instead of reading out the WRPLL/SPLL control values from HW, we can use
> the DPLL state that was already read out, or swapped-to.
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_d
On Wed, Feb 26, 2020 at 10:34:53PM +0200, Imre Deak wrote:
> Split out the PLL parameter->frequency conversion logic for each type of
> PLL for symmetry with their corresponding inverse conversion functions.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 4
Fixes: d54c1a513c48 ("drm/i915: Fix broken transcoder err state")
has_transcoder() was unused because function which was using it,
intel_display_capture_error_state() defined under
CONFIG_DRM_I915_CAPTURE_ERROR.
Moving has_transcoder() to under CONFIG_DRM_I915_CAPTURE_ERROR.
No functional change.
== Series Details ==
Series: series starting with [1/3] drm/i915/vgpu: improve vgpu abstractions
URL : https://patchwork.freedesktop.org/series/74024/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/vgpu: improve vgpu abstractions
Okay!
Commit
On Wed, Feb 26, 2020 at 10:34:55PM +0200, Imre Deak wrote:
> All platforms using the shared DPLL framework use 3 reference clocks for
> their DPLLs: SSC, non-SSC and DSI. For a more unified way across
> platforms store the frequency of these ref clocks as part of the DPLL
> global state. This also
slab does this already, and I want to use this in a memory allocation
tracker in drm for stuff that's tied to the lifetime of a drm_device,
not the underlying struct device. Kinda like devres, but for drm.
Acked-by: Andrew Morton
Signed-off-by: Daniel Vetter
Cc: Christoph Lameter
Cc: Pekka Enbe
Hi all,
Bunch more bugfixes (intel-gfx-ci wasn't fully happy yet, and justifiedly
so) all over, bunch more acks/reviews.
Still need a lot more review and acks. Recommended reading order is still
to start with the doc patch at the end for the big picture, then the code
changes in sequence.
Also c
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
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.
Reviewed-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm
With this we can drop the final kfree from the release function.
Reviewed-by: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/tiny/gm12u320.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm
With this we can drop the final kfree from the release function.
The mock device in the selftests needed it's pci_device split
up from the drm_device. In the future we could simplify this again
by allocating the pci_device as a managed allocation too.
v2: I overlooked that i915_driver_destroy is
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,
They all share mipi_dbi_release so we need to switch them all
together. With this we can drop the final kfree from the release
function.
Aside, I think we could perhaps have a tiny additional helper for
these mipi_dbi drivers, the first few lines around devm_drm_dev_init
are all the same (except f
We need to add a drmm_kstrdup for this, but let's start somewhere.
This is not exactly perfect onion unwinding, but it's jsut a kfree so
doesn't really matter at all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 5 ++---
drivers/gpu/drm/drm_managed.c | 16
A few things:
- Update the example driver in the documentation.
- We can drop the old kfree in drm_dev_release.
- Add a WARN_ON check in drm_dev_register to make sure everyone calls
drmm_add_final_kfree and there's no leaks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 11 -
With this we can drop the final kfree from the release function.
Signed-off-by: Daniel Vetter
Cc: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ing
With this we can drop the final kfree from the release function.
Reviewed-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/repaper.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gp
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Dan
1 - 100 of 259 matches
Mail list logo
