[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Minor Fixes and Refactoring for HDMI PCON stuff (rev2)

== Series Details == Series: Minor Fixes and Refactoring for HDMI PCON stuff (rev2) URL : https://patchwork.freedesktop.org/series/99311/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: Return some errors instead of trying memcpy move

== Series Details == Series: drm/i915/ttm: Return some errors instead of trying memcpy move URL : https://patchwork.freedesktop.org/series/99553/ State : success == Summary == CI Bug Log - changes from CI_DRM_11168 -> Patchwork_22145 Summar

[Intel-gfx] [PATCH v2 4/4] drm/i915/display: Simplify helpers for getting DSC slices and bpp

Genralize the helper for getting DSC slice count and compressed bpp for HDMI sink supporting DSC. This patch: -Removes the assumption on the bpc and sends it as an argument for calculating compressed bpc. -Sends the resolution, and output format as parameters for which the DSC paremeters are to be

[Intel-gfx] [PATCH v2 1/4] drm/i915/hdmi: Fix the definition of intel_hdmi_dsc_get_bpp

Fix the data-type of the argument output_format to enum, for the function intel_hdmi_dsc_get_bpp. v2: Fixed formatting issues in commit message (Jani). Avoided including the header intel_display_types.h, instead used forward declaration for the appropriate enum. (Jani). Fixes: 6e6cb758e035 ("drm/

[Intel-gfx] [PATCH v2 3/4] drm/i915/dp: Use the drm helpers for getting max FRL rate

Re-use the drm helpers for getting max FRL rate for an HDMI sink. This patch removes the duplicate code and calls the already defined drm helpers for the task. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_dp.c | 19 +-- 1 file changed, 5 insertions(+), 14

[Intel-gfx] [PATCH v2 2/4] drm/edid: Add helper to get max FRL rate for an HDMI sink

Add the helpers for getting the max FRL rate with and without DSC for an HDMI sink. v2: Fix the subject line and documentation of the helpers (Jani). Split the helper definitions and usage into separate patches. (Jani). Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/drm_edid.c | 38 +

[Intel-gfx] [PATCH v2 0/4] Minor Fixes and Refactoring for HDMI PCON stuff

Misc fixes and refactoring in HDMI2.1 PCON helper functions. V2: Addressed review comments from Jani. Splitted the drm_helper addition and usage in separate patches. Ankit Nautiyal (4): drm/i915/hdmi: Fix the definition of intel_hdmi_dsc_get_bpp drm/edid: Add helper to get max FRL rate for an

[Intel-gfx] [PATCH] drm/i915/ttm: Return some errors instead of trying memcpy move

The i915_ttm_accel_move() function may return error codes that should be propagated further up the stack rather than consumed assuming that the accel move failed and could be replaced with a memcpy move. For -EINTR, -ERESTARTSYS and -EAGAIN, just propagate those codes, rather than retrying with a

Re: [Intel-gfx] [PATCH 1/3] drm: add writeback pointers to drm_connector

Hey, > I think there are more places affected with this change. I can get below > compilation issues while trying to compile my branch: > > drivers/gpu/drm/vc4/vc4_txp.c: In function ‘encoder_to_vc4_txp’: > ./include/linux/build_bug.h:78:41: error: static assertion failed: > "pointer type mismatch

Re: [Intel-gfx] [PATCH 1/3] drm: add writeback pointers to drm_connector

Hi Suraj I think there are more places affected with this change. I can get below compilation issues while trying to compile my branch: drivers/gpu/drm/vc4/vc4_txp.c: In function ‘encoder_to_vc4_txp’: ./include/linux/build_bug.h:78:41: error: static assertion failed: "pointer type mismatch in

Re: [Intel-gfx] [PATCH v2] drm/i915/display/vrr: Reset VRR capable property on a long hpd

On Mon, Jan 31, 2022 at 02:28:04PM +0200, Jani Nikula wrote: > On Wed, 26 Jan 2022, Manasi Navare wrote: > > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel > > settings. > > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore > > MSA bit > > in th

Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()

Hi Daniel, I love your patch! Perhaps something to improve: [auto build test WARNING on tegra-drm/drm/tegra/for-next] [also build test WARNING on drm/drm-next linus/master v5.17-rc2 next-20220131] [cannot apply to airlied/drm-next] [If your patch is applied to the wrong git tree, kindly drop us

[Intel-gfx] [drm-intel:for-linux-next-fixes 6/7] drivers/gpu/drm/i915/i915_vma.c:451:4: error: 'ret' undeclared; did you mean 'net'?

tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes head: ea33c6d63f87e34b14dba6f2804990a5fc5a60d7 commit: 2e872d87cbf2cd02dca570ee187cf35567576a70 [6/7] drm/i915: delete shadow "ret" variable config: x86_64-randconfig-a003-20220131 (https://download.01.org/0day-

[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

Hi all, After merging the drm-intel-fixes tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/i915/i915_vma.c: In function 'i915_vma_bind': drivers/gpu/drm/i915/i915_vma.c:451:25: error: 'ret' undeclared (first use in this function); did you mean 'net'? 451 |

[Intel-gfx] ✗ Fi.CI.BAT: failure for some fbcon patches, mostly locking

== Series Details == Series: some fbcon patches, mostly locking URL : https://patchwork.freedesktop.org/series/99549/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11166 -> Patchwork_22144 Summary --- **FAILURE**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for some fbcon patches, mostly locking

== Series Details == Series: some fbcon patches, mostly locking URL : https://patchwork.freedesktop.org/series/99549/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for some fbcon patches, mostly locking

== Series Details == Series: some fbcon patches, mostly locking URL : https://patchwork.freedesktop.org/series/99549/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8895b11855ce MAINTAINERS: Add entry for fbdev core -:64: WARNING:MAINTAINERS_STYLE: Misordered MAINTAINERS entry -

[Intel-gfx] ✗ Fi.CI.BAT: failure for discrete card 64K page support (rev4)

== Series Details == Series: discrete card 64K page support (rev4) URL : https://patchwork.freedesktop.org/series/99119/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11166 -> Patchwork_22143 Summary --- **FAILURE**

[Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c

Well except when the olpc dcon fbdev driver is enabled, that thing digs around in there in rather unfixable ways. Cc oldc_dcon maintainers as fyi. Cc: Jens Frederich Cc: Jon Nettleton Cc: Greg Kroah-Hartman Cc: linux-stag...@lists.linux.dev Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc:

[Intel-gfx] [PATCH 17/21] fbcon: Move more code into fbcon_release

con2fb_release_oldinfo() has a bunch more kfree() calls than fbcon_exit(), but since kfree() on NULL is harmless doing that in both places should be ok. This is also a bit more symmetric now again with fbcon_open also allocating the fbcon_ops structure. Signed-off-by: Daniel Vetter Cc: Daniel Vet

[Intel-gfx] [PATCH 20/21] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee. With commit 27599aacbaefcbf2af7b06b0029459bbf682000d Author: Thomas Zimmermann Date: Tue Jan 25 10:12:18 2022 +0100 fbdev: Hot-unplug firmware fb devices on forced removal this should be fixed properly and we can remove this s

[Intel-gfx] [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()

This shouldn't be a problem in practice since until we've actually taken over the console there's nothing we've registered with the console/vt subsystem, so the exit/unbind path that check this can't do the wrong thing. But it's confusing, so fix it by moving it a tad later. Signed-off-by: Daniel

[Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit

There's a bunch of confusions going on here: - The deferred fbcon setup notifier should only be cleaned up from fb_console_exit(), to be symmetric with fb_console_init() - We also need to make sure we don't race with the work, which means temporarily dropping the console lock (or we can deadloc

[Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info

Accessing the one in fbmem.c without taking the right locks is a bad idea. Instead maintain our own private copy, which is fully protected by console_lock() (like everything else in fbcon.c). That copy is serialized through fbcon_fb_registered/unregistered() calls. Also this means we do not need t

[Intel-gfx] [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister

Ideally console_lock becomes an implementation detail of fbcon.c and doesn't show up anywhere in fbmem.c. We're still pretty far from that, but at least the register/unregister code is there now. With this the do_fb_ioctl() handler is the only code in fbmem.c still calling console_lock(). Signed-

[Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()

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. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Greg Kroah-Hartman Cc: Tetsuo Handa Cc: Thomas Zimmerma

[Intel-gfx] [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release

Now we get to the real motiviation, because fbmem.c insists that that's the right lock for these. Ofc fbcon.c has a lot more places where it probably should call lock_fb_info(). But looking at fbmem.c at least most of these seem to be protected by console_lock() too, which is probably what papers

[Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue

It was only used by fbcon, and that now switched to its own, private work. Signed-off-by: Daniel Vetter Cc: Helge Deller Cc: linux-fb...@vger.kernel.org --- include/linux/fb.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/fb.h b/include/linux/fb.h index 02f362c661c8..a8a00d2b

[Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers

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. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Claudio Suarez Cc: Greg Kroa

[Intel-gfx] [PATCH 08/21] fbcon: Use delayed work for cursor

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 fbcon code stops using the fb_info.queue, which help

[Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean

It's only one flag and slightly tidier code. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Tetsuo Handa Cc: Greg Kroah-Hartman Cc: Du Cheng Cc: Thomas Zimmermann Cc: Claudio Suarez --- drivers/video/fbdev/core/fbcon.c | 11 +-- drivers/video/fbdev/core/fbcon.h | 4 +--- 2 fil

[Intel-gfx] [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo

It doesn't ever fail anymore. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Thomas Zimmermann Cc: Greg Kroah-Hartman Cc: Claudio Suarez Cc: Du Cheng Cc: Tetsuo Handa --- drivers/video/fbdev/core/fbcon.c | 37 +++- 1 file changed, 13 insertions(+), 24 deleti

[Intel-gfx] [PATCH 07/21] fbdev/sysfs: Fix locking

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 really variable fbdev state is actually protected

[Intel-gfx] [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup

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 step is to encapsulate the lookup. Signed-off-by:

[Intel-gfx] [PATCH 04/21] fbcon: delete a few unneeded forward decl

I didn't bother with any code movement to fix the others, these just got a bit in the way. Signed-off-by: Daniel Vetter Cc: Helge Deller Cc: Daniel Vetter Cc: Thomas Zimmermann Cc: Du Cheng Cc: Tetsuo Handa Cc: Claudio Suarez Cc: Greg Kroah-Hartman --- drivers/video/fbdev/core/fbcon.c | 1

[Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code

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 fbcon init had to handle the case where fbdev dr

[Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION option. References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723...@gmx.de/ Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling") Cc

[Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

Ever since Tomi extracted the core code in 2014 it's been defacto me maintaining this, with help from others from dri-devel and sometimes Linus (but those are mostly merge conflicts): $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 35 Daniel Vetter 23 Linus Torvalds 10 Hans

[Intel-gfx] [PATCH 02/21] fbcon: Resurrect fbcon accelerated scrolling code

This reverts commit b3ec8cdf457e ("fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"), but with a twist: Because distros like fedora&suse (probably more) really want to move away from fbcon as much as possible, and don't have a need for fancy accelerated fbcon even less

[Intel-gfx] [PATCH 00/21] some fbcon patches, mostly locking

Hi all, This took way longer than I hoped, but well I got lost in head-scratching locking problems. Anyway ended up typing a pile of fbcon patches. Rough overview: - MAINTAINER entry for fbdev core in drm-misc, with the usual group maintainering - The reverts, but with a compile time option. I

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for discrete card 64K page support (rev4)

== Series Details == Series: discrete card 64K page support (rev4) URL : https://patchwork.freedesktop.org/series/99119/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for discrete card 64K page support (rev4)

== Series Details == Series: discrete card 64K page support (rev4) URL : https://patchwork.freedesktop.org/series/99119/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5e8b377b5d22 drm/i915: add needs_compact_pt flag cd0c6d7c7b7b drm/i915: enforce min GTT alignment for discrete

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix header test and log spam on !x86 (rev2)

== Series Details == Series: drm/i915: Fix header test and log spam on !x86 (rev2) URL : https://patchwork.freedesktop.org/series/99344/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11164_full -> Patchwork_22142_full Summa

[Intel-gfx] [PATCH v6 5/5] drm/i915/uapi: document behaviour for DG2 64K support

From: Matthew Auld On discrete platforms like DG2, we need to support a minimum page size of 64K when dealing with device local-memory. This is quite tricky for various reasons, so try to document the new implicit uapi for this. v3: fix typos and less emphasis v2: Fixed suggestions on formatting

[Intel-gfx] [PATCH v6 3/5] drm/i915: support 64K GTT pages for discrete cards

From: Matthew Auld discrete cards optimise 64K GTT pages for local-memory, since everything should be allocated at 64K granularity. We say goodbye to sparse entries, and instead get a compact 256B page-table for 64K pages, which should be more cache friendly. 4K pages for local-memory are no long

[Intel-gfx] [PATCH v6 4/5] drm/i915: add gtt misalignment test

add test to check handling of misaligned offsets and sizes v4: * remove spurious blank lines * explicitly cast intel_region_id to intel_memory_type in misaligned_pin Reported-by: kernel test robot v6: * use NEEDS_COMPACT_PT instead of hard coding for DG2 Signed-off-by: Ro

[Intel-gfx] [PATCH v6 2/5] drm/i915: enforce min GTT alignment for discrete cards

From: Matthew Auld For local-memory objects we need to align the GTT addresses to 64K, both for the ppgtt and ggtt. We need to support vm->min_alignment > 4K, depending on the vm itself and the type of object we are inserting. With this in mind update the GTT selftests to take this into account.

[Intel-gfx] [PATCH v6 1/5] drm/i915: add needs_compact_pt flag

From: Ramalingam C Add a new platform flag, needs_compact_pt, to mark the requirement of compact pt layout support for the ppGTT when using 64K GTT pages. With this flag has_64k_pages will only indicate requirement of 64K GTT page sizes or larger for device local memory access. v6: * mi

[Intel-gfx] [PATCH v6 0/5] discrete card 64K page support

This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lme

Re: [Intel-gfx] [PATCH v2 06/17] drm/i915: Pass crtc+cpu_transcoder to intel_cpu_transcoder_set_m_n()

On Mon, Jan 31, 2022 at 08:29:32PM +0200, Ville Syrjälä wrote: > On Mon, Jan 31, 2022 at 04:37:00PM +0200, Jani Nikula wrote: > > > @@ -2508,15 +2509,16 @@ static void i9xx_crtc_enable(struct > > > intel_atomic_state *state, > > > const struct intel_crtc_state *new_crtc_state = > > > i

Re: [Intel-gfx] [PATCH v2 12/17] drm/i915: Fix intel_cpu_transcoder_has_m2_n2()

On Mon, Jan 31, 2022 at 05:05:53PM +0200, Jani Nikula wrote: > On Fri, 28 Jan 2022, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > M2/N2 values are present for all ilk-ivb,vlv,chv (and hsw edp). > > Make the code reflect that. > > Nitpick, it's not called intel_cpu_transcoder_has_m2_n2() u

Re: [Intel-gfx] [PATCH v2 06/17] drm/i915: Pass crtc+cpu_transcoder to intel_cpu_transcoder_set_m_n()

On Mon, Jan 31, 2022 at 04:37:00PM +0200, Jani Nikula wrote: > > @@ -2508,15 +2509,16 @@ static void i9xx_crtc_enable(struct > > intel_atomic_state *state, > > const struct intel_crtc_state *new_crtc_state = > > intel_atomic_get_new_crtc_state(state, crtc); > > struct drm_i915_

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix header test and log spam on !x86 (rev2)

== Series Details == Series: drm/i915: Fix header test and log spam on !x86 (rev2) URL : https://patchwork.freedesktop.org/series/99344/ State : success == Summary == CI Bug Log - changes from CI_DRM_11164 -> Patchwork_22142 Summary ---

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: s/engine->i915/i915/ for engine workarounds

On Sat, Jan 29, 2022 at 12:51:42AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/dg2: s/engine->i915/i915/ for engine workarounds > URL : https://patchwork.freedesktop.org/series/99484/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_11159_full ->

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/: Re-work clflush_write32

Hey Tvrtko, Are you saying when adding drm_clflush_virt_range(addr, sizeof(addr), this function forces an x86 code path only? If that is the case, drm_clflush_virt_range(addr, sizeof(addr) currently has ifdefs that seperate out x86 and powerpc, so we can add an ifdef for arm in the near futur

[Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message

Only x86 and in some cases PPC have support added in drm_cache.c for the clflush class of functions. However warning once is sufficient to taint the log instead of spamming it with "Architecture has no drm_cache.c support" every few millisecond. Switch to WARN_ONCE() so we still get the log message

[Intel-gfx] [PATCH v3 0/3] drm/i915: Fix header test and log spam on !x86

Some minor fixes and changes to help porting i915 to arm64, or even anything !x86. v3: No changes, just submit to the right mailing list. Lucas De Marchi (3): drm: Stop spamming log with drm_cache message drm/i915: Fix header test for !CONFIG_X86 drm/i915: Do not spam log with missing arch

[Intel-gfx] [PATCH v3 2/3] drm/i915: Fix header test for !CONFIG_X86

Architectures others than x86 have a stub implementation calling WARN_ON_ONCE(). The appropriate headers need to be included, otherwise the header-test target will fail with: HDRTEST drivers/gpu/drm/i915/i915_mm.h In file included from : ./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_ma

[Intel-gfx] [PATCH v3 3/3] drm/i915: Do not spam log with missing arch support

Following what was done in drm_cache.c, when the stub for remap_io_mapping() was added in commit 67c430bbaae1 ("drm/i915: Skip remap_io_mapping() for non-x86 platforms"), it included a log message with pr_err(). However just the warning is already enough and switching to WARN_ONCE() allows us to k

Re: [Intel-gfx] [PATCH 07/20] drm/i915/buddy: track available visible size

On 1/26/22 16:21, Matthew Auld wrote: 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

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Move the power domain->well mappings to intel_display_power_map.c

On Mon, Jan 31, 2022 at 02:15:25PM +0200, Jani Nikula wrote: > On Fri, 28 Jan 2022, Imre Deak wrote: > > Move the list of platform specific power domain -> power well > > definitions to intel_display_power_map.c. While at it group the > > platforms' power domain macros with the corresponding power

Re: [Intel-gfx] [PATCH 06/20] drm/i915: add I915_BO_ALLOC_TOPDOWN

On 31/01/2022 15:28, Thomas Hellström wrote: On 1/26/22 16:21, Matthew Auld wrote: If the user doesn't require CPU access for the buffer, then ALLOC_TOPDOWN should be used, in order to prioritise allocating in the non-mappable portion of LMEM. Signed-off-by: Matthew Auld Cc: Thomas Hellström

Re: [Intel-gfx] [PATCH 06/20] drm/i915: add I915_BO_ALLOC_TOPDOWN

On 1/26/22 16:21, Matthew Auld wrote: If the user doesn't require CPU access for the buffer, then ALLOC_TOPDOWN should be used, in order to prioritise allocating in the non-mappable portion of LMEM. Signed-off-by: Matthew Auld Cc: Thomas Hellström I was wondering how this would work best wit

Re: [Intel-gfx] [PATCH 04/20] drm/i915: add io_size plumbing

On 1/26/22 16:21, Matthew Auld wrote: 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. Signed-off-by: Matthew Auld Cc: T

Re: [Intel-gfx] [PATCH v2 00/17] drm/i915: M/N cleanup

On Fri, 28 Jan 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Rehashed version of the M/N cleanup after Jani (rightly) > complained about the legibility of some of the patches in > the v1 series. These are chunked to a finer pulp, some got > revised a bit, and I left out a few of the FDI re

Re: [Intel-gfx] [PATCH v2 12/17] drm/i915: Fix intel_cpu_transcoder_has_m2_n2()

On Fri, 28 Jan 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > M2/N2 values are present for all ilk-ivb,vlv,chv (and hsw edp). > Make the code reflect that. Nitpick, it's not called intel_cpu_transcoder_has_m2_n2() until in the next patch. Side note, I've also been looking at this bit in i

Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: add needs_compact_pt flag

On 1/31/22 15:19, Robert Beckett wrote: On 27/01/2022 09:37, Thomas Hellström (Intel) wrote: On 1/26/22 18:11, Robert Beckett wrote: On 26/01/2022 13:49, Thomas Hellström (Intel) wrote: On 1/25/22 20:35, Robert Beckett wrote: From: Ramalingam C Add a new platform flag, needs_compact

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/: Re-work clflush_write32

On 28/01/2022 22:10, Michael Cheng wrote: 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 inserti

Re: [Intel-gfx] [PATCH v2 06/17] drm/i915: Pass crtc+cpu_transcoder to intel_cpu_transcoder_set_m_n()

On Fri, 28 Jan 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Instead of passing in the whole crtc state let's pass in just > the bits of state we need. This will help with the DRRS code > which shouldn't really be accessing the atomic state stuff directly > as it gets called outside the no

Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: add needs_compact_pt flag

On 27/01/2022 09:37, Thomas Hellström (Intel) wrote: On 1/26/22 18:11, Robert Beckett wrote: On 26/01/2022 13:49, Thomas Hellström (Intel) wrote: On 1/25/22 20:35, Robert Beckett wrote: From: Ramalingam C Add a new platform flag, needs_compact_pt, to mark the requirement of compact pt

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Re-work invalidate_csb_entries

Tvrtko Ursulin writes: > On 28/01/2022 22:10, Michael Cheng wrote: >> Re-work invalidate_csb_entries 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_execlist

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Re-work invalidate_csb_entries

On 28/01/2022 22:10, Michael Cheng wrote: Re-work invalidate_csb_entries 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_execlists_submission.c | 4 ++-- 1 file changed,

Re: [Intel-gfx] [PATCH - v3] drm/i915: Discard large BIOS framebuffers causing display corruption.

> On 12-Jan-2022, at 7:07 PM, Ville Syrjälä > wrote: > > On Tue, Jan 11, 2022 at 07:55:22AM +, Ashish Arora wrote: >> From: Ashish Arora >> >> On certain 4k panels and Macs, the BIOS framebuffer is larger than what >> panel requires causing display corruption. Introduce a check for the s

Re: [Intel-gfx] [PATCH v2] drm/i915/display/vrr: Reset VRR capable property on a long hpd

On Wed, 26 Jan 2022, Manasi Navare wrote: > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel > settings. > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore > MSA bit > in the DPCD. Currently the driver parses that onevery HPD but fails to reset >

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Move the power domain->well mappings to intel_display_power_map.c

On Fri, 28 Jan 2022, Imre Deak wrote: > Move the list of platform specific power domain -> power well > definitions to intel_display_power_map.c. While at it group the > platforms' power domain macros with the corresponding power well lists > and keep all the power domain lists in the same order (

Re: [Intel-gfx] [PATCH v5 3/5] drm/i915: support 64K GTT pages for discrete cards

On 1/25/22 20:35, Robert Beckett wrote: From: Matthew Auld discrete cards optimise 64K GTT pages for local-memory, since everything should be allocated at 64K granularity. We say goodbye to sparse entries, and instead get a compact 256B page-table for 64K pages, which should be more cache fri

Re: [Intel-gfx] [PATCH 4/5] drm/i915/dg2: Add Wa_22011100796

On Fri, 28 Jan 2022 at 18:52, Ramalingam C wrote: > > From: Bruce Chang > > Whenever Full soft reset is required, reset all individual engines > first, and then do a full soft reset. > > Signed-off-by: Bruce Chang > cc: Matt Roper > Cc: Rodrigo Vivi > Signed-off-by: Ramalingam C Acked-by: Mat

Re: [Intel-gfx] [PATCH 2/5] drm/i915: align the plane_vma to min_page_size of stolen mem

On Mon, 31 Jan 2022 at 10:18, Matthew Auld wrote: > > On 28/01/2022 18:52, Ramalingam C wrote: > > Align the plane vma size to the stolem memory regions' min_page_size. > > > > Signed-off-by: Ramalingam C > > cc: Matthew Auld > > cc: Chris P Wilson > Reviewed-by: Matthew Auld Do you know for

Re: [Intel-gfx] [PATCH 3/5] drm/i915: More gt idling time with guc submission

On 28/01/2022 18:52, Ramalingam C wrote: On i915_selftest@live@gt_timelines, we create many contexts in loop and create and submit request and then destoy contexts. Destroying the context needs to disable scheduling, wait for G2H, deregister context and wait for G2H to destroy each context. Idlin

Re: [Intel-gfx] [PATCH 2/5] drm/i915: align the plane_vma to min_page_size of stolen mem

On 28/01/2022 18:52, Ramalingam C wrote: Align the plane vma size to the stolem memory regions' min_page_size. Signed-off-by: Ramalingam C cc: Matthew Auld cc: Chris P Wilson Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH] drm/i915/dg2: s/engine->i915/i915/ for engine workarounds

On 28/01/2022 17:01, Matt Roper wrote: rcs_engine_wa_init() has a local 'i915' variable; we should use that rather than 'engine->i915' for consistency with how we handle other platforms. Suggested-by: Tvrtko Ursulin Signed-off-by: Matt Roper Reviewed-by: Tvrtko Ursulin Regards, Tvrtko