== Series Details ==
Series: drm/i915/selftests: Disable runtime pm wakeref tracking for the mock
device (rev3)
URL : https://patchwork.freedesktop.org/series/99708/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be ch
== Series Details ==
Series: drm/i915: Futher optimize plane updates (rev3)
URL : https://patchwork.freedesktop.org/series/99149/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11207_full -> Patchwork_22234_full
Summary
== Series Details ==
Series: drm/i915/selftests: Disable runtime pm wakeref tracking for the mock
device (rev3)
URL : https://patchwork.freedesktop.org/series/99708/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11207 -> Patchwork_22236
===
+Tvrtko
On Wed, 09 Feb 2022, "Wang, Zhi A" wrote:
> Hi folks:
>
> Ping. This pull seems not got merged.
>
> Thanks,
> Zhi.
>
> -Original Message-
> From: Zhi Wang
> Sent: Saturday, January 15, 2022 12:46 PM
> To: Vivi, Rodrigo ; jani.nik...@linux.intel.com;
> joonas.lahti...@linux.in
== Series Details ==
Series: drm/i915: Clarify vma lifetime
URL : https://patchwork.freedesktop.org/series/99948/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11207_full -> Patchwork_22235_full
Summary
---
**FAILURE
On Wed, Feb 09, 2022 at 03:17:38PM -0500, Waiman Long wrote:
>
> On 2/9/22 14:45, Namhyung Kim wrote:
> > On Wed, Feb 9, 2022 at 11:28 AM Mathieu Desnoyers
> > wrote:
> > > - On Feb 9, 2022, at 2:22 PM, Namhyung Kim namhy...@kernel.org wrote:
> > > > I'm also concerning dynamic allocated lock
Hi Dave and Daniel,
here's this week's PR for drm-misc-fixes. The most notable thing is the
addition of the new fbdev core module.
Best regards
Thomas
drm-misc-fixes-2022-02-10:
* drm/panel: simple: Fix assignments from panel_dpi_probe()
* drm/privacy-screen: Cleanups
* drm/rockchip: Fix HDMI
== Series Details ==
Series: drm/i915/selftests: Disable runtime pm wakeref tracking for the mock
device (rev3)
URL : https://patchwork.freedesktop.org/series/99708/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11207_full -> Patchwork_22236_full
=
On Wed, Feb 09, 2022 at 04:32:58PM -0800, Namhyung Kim wrote:
> On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra wrote:
> >
> > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote:
> >
> > > Eventually I'm mostly interested in the contended locks only and I
> > > want to reduce the overhead
Feel free to let me know if I need to re-base on the newest tag since it has
been quite some time.
On 2/10/22 8:51 AM, Jani Nikula wrote:
>
> +Tvrtko
>
> On Wed, 09 Feb 2022, "Wang, Zhi A" wrote:
>> Hi folks:
>>
>> Ping. This pull seems not got merged.
>>
>> Thanks,
>> Zhi.
>>
>> -Original
From: Ville Syrjälä
We lost the required >>16 when I refactored the FBC plane state
checks. Bring it back so the check does what it's supposed to.
Cc: Mika Kahola
Fixes: 2e6c99f88679 ("drm/i915/fbc: Nuke lots of crap from
intel_fbc_state_cache")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/d
On 10/02/2022 01:26, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache.
Resend of https://patchwork.freedesktop.org/series/98836/
Jani Nikula (5):
drm/i915/opregion: check port number bounds for SWSCI display power
state
drm/i915/opregion: abstract the check for valid swsci function
drm/i915/opregion: early exit from encoder notify if SWSCI isn't there
drm
The mapping from enum port to whatever port numbering scheme is used by
the SWSCI Display Power State Notification is odd, and the memory of it
has faded. In any case, the parameter only has space for ports numbered
[0..4], and UBSAN reports bit shift beyond it when the platform has port
F or more.
Add a reusable function for checking the SWSCI function.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 30 +--
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drive
Newer platforms aren't supposed to have mailbox #2 or SWSCI
support. Bail out early from encoder notify if that is the case,
skipping the out-of-bounds checks and debug messages.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 6 ++
1 file ch
Opregion Mailbox #2 is obsolete for SWSCI usage in opregion v2.x, and
repurposed in opregion v3.x. Warn about obsole mailbox presence in v2.x,
and ignore with an error for v3.x.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 14 +++---
1
Start debug logging about the presence of the new Mailbox #2 for
backlight. Actual support is to be added later.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drive
On Thu, 10 Feb 2022, Chuansheng Liu wrote:
> Current DMC_DEBUG3(_MMIO(0x101090)) address is for TGL,
> it is not wrong for DG1. Just like commit 5bcc95ca382e
wrong, not "not wrong".
BR,
Jani.
> ("drm/i915/dg1: Update DMC_DEBUG register"), correct
> this issue for DG1 platform to avoid wrong reg
Hi Dave, Daniel,
An assortment of fixes for -rc4, mostly display, one TTM migration fixup,
one fix for platforms without runtime PM and one !x86 build fix.
Regards,
Tvrtko
drm-intel-fixes-2022-02-10:
- Build fix for non-x86 platforms after remap_io_mmapping changes. (Lucas De
Marchi)
- Corr
On Tue, 08 Feb 2022, José Roberto de Souza wrote:
> A new programming step was added to combo and TC PLL sequences.
> If override_AFC_startup is set in VBT, driver should overwrite
> AFC_startup value to 0x7 in PLL's div0 register.
>
> The current understating is that only TGL needs this and all d
On 10/02/2022 10:14, Wang, Zhi A wrote:
Feel free to let me know if I need to re-base on the newest tag since it has
been quite some time.
Sorry I did not see this. I will pull it next Monday. If you can extra
remind me it would be appreciated.
Current base for fixes is 5.17-rc3 but given
On Thu, Feb 10, 2022 at 12:36:46PM +0200, Jani Nikula wrote:
> Start debug logging about the presence of the new Mailbox #2 for
> backlight. Actual support is to be added later.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_opregion.c | 13 +++
On 09/02/2022 05:25, Casey Bowman wrote:
On 2/7/22 07:36, Tvrtko Ursulin wrote:
On 20/01/2022 22:16, Casey Bowman wrote:
In this RFC I would like to ask the community their thoughts
on how we can best handle splitting architecture-specific
calls.
I would like to address the following:
1.
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
v2: Rebase on top of Helge's reverts.
Acked-by: Sam Ravnborg (v1)
Reviewed-by: Geert Uytterhoeven (v1)
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: D
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Signed-off-by: Daniel Vet
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First ste
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because re
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbco
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
It was only used by fbcon, and that now switched to its own,
private work.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Acked-by: Thomas Zimmermann
---
include/linux/fb.h | 1 -
1 fil
Hi
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c
== Series Details ==
Series: drm/i915: Futher optimize plane updates (rev4)
URL : https://patchwork.freedesktop.org/series/99149/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11211 -> Patchwork_22237
Summary
---
**S
On 2022/02/09 6:08, Daniel Vetter wrote:
> @@ -714,6 +700,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> struct fb_info *info,
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> if (!ops)
> err = -ENOMEM;
> +
> + INI
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This series
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
v2: also update intelfb_create
Signed-off-by: Matthew Auld
Cc: Thomas Hell
On devices with non-mappable LMEM ensure we always allocate the pages
within the mappable portion. For now we assume that all LMEM buffers
will require CPU access, which is also inline with pretty much all
current kernel internal users. In the next patch we will introduce a new
flag to override thi
If the user doesn't require CPU access for the buffer, then
ALLOC_GPU_ONLY should be used, in order to prioritise allocating in the
non-mappable portion of LMEM, on devices with small BAR.
v2(Thomas):
- The BO_ALLOC_TOPDOWN naming here is poor, since this is pure lies on
systems that don't e
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the per-resource visible usage
will be useful for
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftest
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing an error.
Also it looks like TTM will re
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hells
If we need to make room for some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way we hope
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable pla
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU access.
In a later patch userspace will be
Differentiate between mappable vs non-mappable resources, also if this
is an actual range allocation ensure we set res->start as the starting
pfn. Later when we need to do non-mappable -> mappable moves then we
want TTM to see that the current placement is not compatible, which
should result in an
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c |
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't impact DG1.
v2(Reported-by: kernel test rob
If set, force the allocation to be placed in the mappable portion of
LMEM. One big restriction here is that system memory must be given as a
potential placement for the object, that way we can always spill the
object into system memory if we can't make space.
XXX: Still very much WIP and needs IGT
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 6
LGTM
Reviewed-by: Ankit Nautiyal
On 10/15/2021 7:09 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Just loop over the possible bpc values instead of
using an ugly if construct.
A slight change in behaviour is that we now call
intel_hdmi_{source,sink}_bpc_possible() even for 8bpc,
but that is f
LGTM
Reviewed-by: Ankit Nautiyal
On 10/15/2021 7:09 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Reuse intel_hdmi_tmds_clock() for DP->HDMI TMDS clock calculations.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 20 +---
drivers/gpu/drm/i915
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
It doesn't ever fail anymore.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Greg Kroah-Hartman
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Tetsuo Handa
Acked-by: Thomas Zimmermann
---
drivers/v
== Series Details ==
Series: drm/i915/fbc: Fix the plane end Y offset check
URL : https://patchwork.freedesktop.org/series/99958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11212 -> Patchwork_22238
Summary
---
**S
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Note that the error handling for the con2fb_acquire_newinfo()
On Tue, 08 Feb 2022, Matt Roper wrote:
> Another collection of cleanup patches for intel_gt_regs.h to make it a
> bit less painful to work with.
I didn't review this but I agree with what's being done.
Acked-by: Jani Nikula
>
> Cc: Jani Nikula
>
> Matt Roper (6):
> drm/i915/gt: Drop duplica
On Thu, 10 Feb 2022, Jani Nikula wrote:
> On Tue, 08 Feb 2022, Matt Roper wrote:
>> Another collection of cleanup patches for intel_gt_regs.h to make it a
>> bit less painful to work with.
>
> I didn't review this but I agree with what's being done.
>
> Acked-by: Jani Nikula
PS. We somehow ende
== Series Details ==
Series: drm/i915: Futher optimize plane updates (rev4)
URL : https://patchwork.freedesktop.org/series/99149/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11211_full -> Patchwork_22237_full
Summary
Patches: 1, 2, 3, 5, 6, 11 are Acked-by: Nirmoy Das
Patches: 5,6 are Reviewed-by: Nirmoy Das
Sorry for partial reviews, I still need to go through more i915 code.
Regards,
Nirmoy
On 10/02/2022 13:12, Matthew Auld wrote:
Starting from DG2 we will have resizable BAR support for device loca
== Series Details ==
Series: drm/i915/opregion: fixes and cleanups, RESEND
URL : https://patchwork.freedesktop.org/series/99961/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c30930dcbba4 drm/i915/opregion: check port number bounds for SWSCI display
power state
e7b41b2e3f18 dr
== Series Details ==
Series: Initial support for small BAR recovery (rev3)
URL : https://patchwork.freedesktop.org/series/99370/
State : failure
== Summary ==
Applying: drm/i915: add io_size plumbing
Applying: drm/i915/ttm: require mappable by default
Applying: drm/i915: add I915_BO_ALLOC_GPU_
> -Original Message-
> From: Ville Syrjala
> Sent: Thursday, February 10, 2022 12:31 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika
> Subject: [PATCH] drm/i915/fbc: Fix the plane end Y offset check
>
> From: Ville Syrjälä
>
> We lost the required >>16 when I refactored the
== Series Details ==
Series: drm/i915/opregion: fixes and cleanups, RESEND
URL : https://patchwork.freedesktop.org/series/99961/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11213 -> Patchwork_22239
Summary
---
**FA
I've sent parts of this before. Another rebase round.
Jani Nikula (14):
drm/i915: split out i915_gem_internal.h from i915_drv.h
drm/i915: remove leftover i915_gem_pm.h declarations from i915_drv.h
drm/i915: split out gem/i915_gem_dmabuf.h from i915_drv.h
drm/i915: split out gem/i915_gem_cr
We already have the i915_gem_internal.c file.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dsb.c | 2 ++
drivers/gpu/drm/i915/display/intel_overlay.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 1 +
drivers/gpu/drm/i
Remove the duplicates.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/i915_gem.c | 1 +
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_d
We already have the gem/i915_gem_dmabuf.c file.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h | 18 ++
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++
drivers
We already have the gem/i915_gem_create.c file.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_create.h | 17 +
drivers/gpu/drm/i915/i915_driver.c | 1 +
drivers/g
We already have the gem/i915_gem_domain.c file.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dpt.c| 4 +++-
drivers/gpu/drm/i915/display/intel_fb_pin.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 5 +++--
drivers/gpu/drm
Move the function next to the only user.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 11 ---
drivers/gpu/drm/i915/i915_debugfs.c | 11 +++
drivers/gpu/drm/i915/i915_drv.h | 2 --
3 files change
Move the function next to the only user. Arguably it's perhaps not the
best place, but it's much better than having a static inline in a
header.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +++
drivers/gpu/drm
It doesn't help much, as i915_drv.h includes i915_gpu_error.h, but it's
a step in the right direction.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 11 ---
drivers/gpu/drm/i915/i915_gpu_error.h | 11 +++
2 files cha
Limit the scope of struct drm_i915_file_private to the files that
actually need it.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 1 +
drivers/gpu/drm/i915/gem/i915_ge
Include it only in files that use it.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 ++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_mman.c| 2 ++
drivers/gpu/drm/i915/
Don't include shmem_fs.h in i915_drv.h, reducing the build dependencies.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 1 -
3 fil
Include drm_fourcc.h, drm_plane.h, and drm_color_mgmt.h where needed, so
we can drop the includes for drm_atomic.h and drm_fourcc.h from
i915_drv.h, reducing the build dependencies.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_create.c |
It's fairly difficult to ensure these are actually not needed due to
indirect includes via other files. However, it's easier to add them back
as needed and, most importantly, where needed instead of exhaustively
proving they're unnecessary.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jan
Group and sort includes in i915_drv.h similar to other places.
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/
On 27/01/2022 14:11, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation a
Opregion Mailbox #2 is obsolete for SWSCI usage in opregion v2.x, and
repurposed in opregion v3.x. Warn about obsole mailbox presence in v2.x,
and ignore with an error for v3.x.
v2: Demote drm_warn() to drm_dbg() on opregion v2.x
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm
On Thu, 10 Feb 2022, Ville Syrjälä wrote:
> On Thu, Feb 10, 2022 at 12:36:46PM +0200, Jani Nikula wrote:
>> Start debug logging about the presence of the new Mailbox #2 for
>> backlight. Actual support is to be added later.
>>
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> driver
== Series Details ==
Series: drm/i915: drm_i915.h cleanup
URL : https://patchwork.freedesktop.org/series/99979/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2e49d59d1b68 drm/i915: split out i915_gem_internal.h from i915_drv.h
-:50: WARNING:FILE_PATH_CHANGES: added, moved or de
== Series Details ==
Series: drm/i915: drm_i915.h cleanup
URL : https://patchwork.freedesktop.org/series/99979/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
DMC_DEBUGU3 changes from DG1+
Bspec: 49788
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 6 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i
== Series Details ==
Series: drm/i915: drm_i915.h cleanup
URL : https://patchwork.freedesktop.org/series/99979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11214 -> Patchwork_22241
Summary
---
**SUCCESS**
No reg
== Series Details ==
Series: drm/i915/opregion: fixes and cleanups, RESEND (rev2)
URL : https://patchwork.freedesktop.org/series/99961/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a8ab1a151539 drm/i915/opregion: check port number bounds for SWSCI display
power state
e88f72d2
== Series Details ==
Series: drm/i915/fbc: Fix the plane end Y offset check
URL : https://patchwork.freedesktop.org/series/99958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11212_full -> Patchwork_22238_full
Summary
On 10/02/2022 16:44, Anusha Srivatsa wrote:
DMC_DEBUGU3 changes from DG1+
Bspec: 49788
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 6 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 5 insertions(+), 2 deleti
== Series Details ==
Series: drm/i915/opregion: fixes and cleanups, RESEND (rev2)
URL : https://patchwork.freedesktop.org/series/99961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11214 -> Patchwork_22242
Summary
---
On 10/02/2022 15:45, Jani Nikula wrote:
I've sent parts of this before. Another rebase round.
All look good to me.
Acked-by: Tvrtko Ursulin
Going forward you can maybe impress the readers even more by including
the before/after of your header tree / depth counter script. :)
Regards,
Tv
On 08/02/2022 11:20, Arunpravin wrote:
On 04/02/22 6:53 pm, Christian König wrote:
Am 04.02.22 um 12:22 schrieb Arunpravin:
On 28/01/22 7:48 pm, Matthew Auld wrote:
On Thu, 27 Jan 2022 at 14:11, Arunpravin
wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add r
== Series Details ==
Series: drm/i915/dg1: Update DMC_DEBUG3 register (rev2)
URL : https://patchwork.freedesktop.org/series/99942/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/dg1: Update DMC_DEBUG3 register (rev2)
URL : https://patchwork.freedesktop.org/series/99942/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11214 -> Patchwork_22243
Summary
---
**
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Signed-of
Replace all occurrence of cache_clflush_range with drm_clflush_virt_range.
This will prevent compile errors on non-x86 platforms.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building for non-x86 architectures.
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range.
Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache.
v3 (Michael Cheng): Remove ifdef for asm/cach
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/driv
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu
1 - 100 of 158 matches
Mail list logo
