Hi again,
> > > finally... pushed in drm-intel-gt-next! :)
> >
> > I had to revert this (uapi commit only) by force pushing, luckily it was the
> > top commit.
>
> OK, sorry!
>
> > 1)
> > IGT is not merged yet.
>
> if igt is merged without the kernel it would fail, though.
can we at least
On Wed, 2023-05-24 at 12:00 +0100, Tvrtko Ursulin wrote:
> On 24/05/2023 10:05, Luca Coelho wrote:
> > In order to avoid flush_scheduled_work() usage, add a dedicated
> > workqueue in the drm_i915_private structure. In this way, we don't
> > need to use the system queue anymore.
> >
> > This
Hi Tvrtko,
> > finally... pushed in drm-intel-gt-next! :)
>
> I had to revert this (uapi commit only) by force pushing, luckily it was the
> top commit.
OK, sorry!
> 1)
> IGT is not merged yet.
if igt is merged without the kernel it would fail, though.
> 2)
> The
== Series Details ==
Series: drm/i915/perf: Clear out entire reports after reading if not power of 2
size (rev3)
URL : https://patchwork.freedesktop.org/series/118151/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13180_full -> Patchwork_118151v3_full
On 24/05/2023 12:56, Tvrtko Ursulin wrote:
On 23/05/2023 09:37, Andi Shyti wrote:
Hi Fei,
finally... pushed in drm-intel-gt-next! :)
I had to revert this (uapi commit only) by force pushing, luckily it was
the top commit.
1)
IGT is not merged yet.
2)
The
On 23/05/2023 09:37, Andi Shyti wrote:
Hi Fei,
finally... pushed in drm-intel-gt-next! :)
I had to revert this (uapi commit only) by force pushing, luckily it was
the top commit.
1)
IGT is not merged yet.
2)
The tools/include/uapi/drm/i915_drm.h part of the patch was not removed.
On 23/05/2023 16:19, Ashutosh Dixit wrote:
No functional changes but we can remove some unsightly index computation
and read/write functions if we convert the PMU sample array from a
one-dimensional to a two-dimensional array.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Ashutosh Dixit
---
On Wed, 24 May 2023, pengfuyuan wrote:
> The test robot reports some make warnings.
>
> Fix those warnings:
> drivers/gpu/drm/i915/i915_gpu_error.c:2174: warning: Function parameter
> or member 'dump_flags' not described in 'i915_capture_error_state'
>
== Series Details ==
Series: drm/i915: implement internal workqueues (rev2)
URL : https://patchwork.freedesktop.org/series/117618/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13181 -> Patchwork_117618v2
Summary
---
On 24/05/2023 12:00, Tvrtko Ursulin wrote:
On 24/05/2023 10:05, Luca Coelho wrote:
8<
if (pool_free_older_than(pool, HZ))
- schedule_delayed_work(>work,
- round_jiffies_up_relative(HZ));
+ queue_delayed_work(gt->i915->unordered_wq, >work,
+
== Series Details ==
Series: drm/i915: implement internal workqueues (rev2)
URL : https://patchwork.freedesktop.org/series/117618/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: implement internal workqueues (rev2)
URL : https://patchwork.freedesktop.org/series/117618/
State : warning
== Summary ==
Error: dim checkpatch failed
e66f4bf055e1 drm/i915: use pointer to i915 instead of rpm in wakeref
9367ad3a84f8 drm/i915: add a
On 24/05/2023 10:05, Luca Coelho wrote:
Instead of using a global workqueue for the SW fence selftest,
allocate a separate one temporarily only while running the test.
Cc: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Luca Coelho
---
On 24/05/2023 10:05, Luca Coelho wrote:
In order to avoid flush_scheduled_work() usage, add a dedicated
workqueue in the drm_i915_private structure. In this way, we don't
need to use the system queue anymore.
This change is mostly mechanical and based on Tetsuo's original
patch[1].
Link:
On 24/05/2023 10:05, Luca Coelho wrote:
Currently a pointer to an intel_runtime_pm structure is stored in the
wake reference structures so the runtime data can be accessed. We can
save the entire device information (drm_i915_private) instead, since
we'll need to reference the new workqueue
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
and fb_sys_() helpers. The DRM functions don't provide any additional
functionality for most DRM drivers. So remove them and call the fbdev
I/O helpers directly.
The DRM fbdev I/O wrappers were originally added because
does
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
On 23.05.2023 17:19, Ashutosh Dixit wrote:
No functional changes but we can remove some unsightly index computation
and read/write functions if we convert the PMU sample array from a
one-dimensional to a two-dimensional array.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Ashutosh Dixit
On 23.05.2023 17:19, Ashutosh Dixit wrote:
pmu_needs_timer() keeps the timer running even when GT is parked,
ostensibly to sample requested/actual frequencies. However
frequency_sample() has the following:
/* Report 0/0 (actual/requested) frequency while parked. */
if
Instead of using a global workqueue for the SW fence selftest,
allocate a separate one temporarily only while running the test.
Cc: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Luca Coelho
---
drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 16
Hi,
This series implements internal workqueues in the i915 driver in order
to avoid using the system queue. We add one generic workqueue in the
drm_i915_private structure, one specific for wake references and one
in a self-test.
This is based on Tetsuo's work[1] and is required to get rid of
Currently a pointer to an intel_runtime_pm structure is stored in the
wake reference structures so the runtime data can be accessed. We can
save the entire device information (drm_i915_private) instead, since
we'll need to reference the new workqueue we'll add in subsequent
patches.
Cc: Tvrtko
In order to avoid flush_scheduled_work() usage, add a dedicated
workqueue in the drm_i915_private structure. In this way, we don't
need to use the system queue anymore.
This change is mostly mechanical and based on Tetsuo's original
patch[1].
Link:
== Series Details ==
Series: Add vfio_device cdev for iommufd support (rev14)
URL : https://patchwork.freedesktop.org/series/113696/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/14/mbox/ not
applied
Applying: vfio: Allocate per
> From: Liu, Yi L
> Sent: Wednesday, May 24, 2023 10:41 AM
>
> > From: Tian, Kevin
> > Sent: Wednesday, May 24, 2023 10:39 AM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, May 24, 2023 10:21 AM
> > >
> > > > >
> > > > > vfio_device_open_file()
> > > > > {
> > > > >
Hi Alex,
I've two new patches to address the comment in this patch. If
it makes sense then I'll put them in cdev v12.
> From: Liu, Yi L
> Sent: Tuesday, May 23, 2023 10:13 AM
>
> > From: Alex Williamson
> > Sent: Tuesday, May 23, 2023 7:04 AM
> >
> > On Sat, 13 May 2023 06:28:25 -0700
> > Yi
== Series Details ==
Series: drm/i915/pmu: couple of cleanups
URL : https://patchwork.freedesktop.org/series/118225/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13177_full -> Patchwork_118225v1_full
Summary
---
On Tue, 2023-05-23 at 16:14 +0300, Jani Nikula wrote:
> On Tue, 23 May 2023, "Govindapillai, Vinod"
> wrote:
> > On Tue, 2023-05-23 at 12:01 +0300, Jani Nikula wrote:
> > > On Tue, 23 May 2023, Vinod Govindapillai
> > > wrote:
> > > > From MTL onwwards, pcode locks the QGV point based on peak
101 - 140 of 140 matches
Mail list logo
