[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/adlp: Disable underrun recovery

== Series Details == Series: drm/i915/display/adlp: Disable underrun recovery URL : https://patchwork.freedesktop.org/series/96548/ State : success == Summary == CI Bug Log - changes from CI_DRM_10836 -> Patchwork_21514 Summary ---

Re: [Intel-gfx] [PATCH v9 10/10] drm: use DEFINE_DYNAMIC_DEBUG_TRACE_CATEGORIES bitmap to tracefs

On 10/27/21 12:36 AM, Jim Cromie wrote: > Use new macro to create a sysfs control bitmap knob to control > print-to-trace in: /sys/module/drm/parameters/trace > > todo: reconsider this api, ie a single macro expecting both debug & > trace terms (2 each), followed by a single description and

[Intel-gfx] [PATCH] drm/i915/display/adlp: Disable underrun recovery

It was also defeatured for ADL-P and other platforms. BSpec: 55424 Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display.c | 39 1 file changed, 7 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Fix synchronization of PMU callback with reset

== Series Details == Series: drm/i915/pmu: Fix synchronization of PMU callback with reset URL : https://patchwork.freedesktop.org/series/96543/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10834_full -> Patchwork_21513_full

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc/slpc: Update boost sysfs hooks for SLPC

On Mon, 01 Nov 2021 18:26:08 -0700, Vinay Belgaumkar wrote: > > Add a helper to sort through the SLPC/RPS paths of get/set methods. > Boost frequency will be modified as long as it is within the constraints > of RP0 and if it is different from the existing one. We will set min > freq to boost only

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc/slpc: Update boost sysfs hooks for SLPC

On Mon, 01 Nov 2021 13:28:14 -0700, Dixit, Ashutosh wrote: > > On Sun, 31 Oct 2021 21:39:37 -0700, Belgaumkar, Vinay wrote: > > > > +static int set_boost_freq(struct intel_rps *rps, u32 val) > > Since this is legacy rps code path maybe change function name to > rps_set_boost_freq? Not being able

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc/slpc: Add waitboost functionality for SLPC

On Mon, 01 Nov 2021 18:26:07 -0700, Vinay Belgaumkar wrote: > > Add helper in RPS code for handling SLPC and non-SLPC paths. > When boost is requested in the SLPC path, we can ask GuC to ramp > up the frequency req by setting the minimum frequency to boost freq. > Reset freq back to the min

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc/slpc: Define and initialize boost frequency

On Mon, 01 Nov 2021 18:26:06 -0700, Vinay Belgaumkar wrote: > > Define helpers and struct members required to record boost info. > Boost frequency is initialized to RP0 at SLPC init. Also define num_waiters > which can track the pending boost requests. > > Boost will be done by scheduling a worker

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

On 11/3/2021 14:38, Jordan Justen wrote: John Harrison writes: On 11/1/2021 08:39, Jordan Justen wrote: writes: From: Rodrigo Vivi GuC contains a consolidated table with a bunch of information about the current device. Previously, this information was spread and hardcoded to all the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Fix synchronization of PMU callback with reset

== Series Details == Series: drm/i915/pmu: Fix synchronization of PMU callback with reset URL : https://patchwork.freedesktop.org/series/96543/ State : success == Summary == CI Bug Log - changes from CI_DRM_10834 -> Patchwork_21513 Summary

[Intel-gfx] [PATCH] drm/i915/pmu: Fix synchronization of PMU callback with reset

Since the PMU callback runs in irq context, it synchronizes with gt reset using the reset count. We could run into a case where the PMU callback could read the reset count before it is updated. This has a potential of corrupting the busyness stats. In addition to the reset count, check if the

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/perf: Detect offset in context image for OA ctx control reg (rev2)

== Series Details == Series: drm/i915/perf: Detect offset in context image for OA ctx control reg (rev2) URL : https://patchwork.freedesktop.org/series/96507/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10834_full -> Patchwork_21512_full

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

John Harrison writes: > On 11/1/2021 08:39, Jordan Justen wrote: >> writes: >> >>> From: Rodrigo Vivi >>> >>> GuC contains a consolidated table with a bunch of information about the >>> current device. >>> >>> Previously, this information was spread and hardcoded to all the components >>>

Re: [Intel-gfx] [PATCH 2/3] drm/i915/dg2: Add initial gt/ctx/engine workarounds

> -Original Message- > From: Roper, Matthew D > Sent: Tuesday, November 2, 2021 3:25 PM > To: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Roper, Matthew D > ; Srivatsa, Anusha > > Subject: [PATCH 2/3] drm/i915/dg2: Add initial gt/ctx/engine workarounds > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Detect offset in context image for OA ctx control reg (rev2)

== Series Details == Series: drm/i915/perf: Detect offset in context image for OA ctx control reg (rev2) URL : https://patchwork.freedesktop.org/series/96507/ State : success == Summary == CI Bug Log - changes from CI_DRM_10834 -> Patchwork_21512

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: Detect offset in context image for OA ctx control reg (rev2)

== Series Details == Series: drm/i915/perf: Detect offset in context image for OA ctx control reg (rev2) URL : https://patchwork.freedesktop.org/series/96507/ State : warning == Summary == $ dim checkpatch origin/drm-tip d73e6124b5f9 drm/i915/perf: Detect offset in context image for OA ctx

[Intel-gfx] [PATCH] drm/i915/perf: Detect offset in context image for OA ctx control reg

Not for review. Just trying out a selftest on CI machines. Signed-off-by: Umesh Nerlige Ramappa --- drivers/gpu/drm/i915/selftests/i915_perf.c | 114 - 1 file changed, 113 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c

Re: [Intel-gfx] [PATCH 8/8] drm/amdgpu: add drm buddy support to amdgpu

On 25/10/2021 14:00, Arunpravin wrote: - Remove drm_mm references and replace with drm buddy functionalities - Add res cursor support for drm buddy Signed-off-by: Arunpravin + spin_lock(>lock); + r = drm_buddy_alloc(mm, (uint64_t)place->fpfn << PAGE_SHIFT, +

Re: [Intel-gfx] [PATCH 6/8] drm/i915: add free_unused_pages support to i915

On 25/10/2021 14:00, Arunpravin wrote: add drm_buddy_free_unused_pages() support on contiguous allocation Signed-off-by: Arunpravin --- drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c

Re: [Intel-gfx] [PATCH 5/8] drm: Implement method to free unused pages

On 25/10/2021 14:00, Arunpravin wrote: On contiguous allocation, we round up the size to the *next* power of 2, implement a function to free the unused pages after the newly allocate block. Signed-off-by: Arunpravin Ideally this gets added with some user, so we can see it in action? Maybe

Re: [Intel-gfx] [PATCH 3/8] drm: implement top-down allocation method

On 25/10/2021 14:00, Arunpravin wrote: Implemented a function which walk through the order list, compares the offset and returns the maximum offset block, this method is unpredictable in obtaining the high range address blocks which depends on allocation and deallocation. for instance, if driver

Re: [Intel-gfx] [PATCH i-g-t 4/8] tests/i915/gem_exec_capture: Use contexts and engines properly

On 11/3/2021 02:36, Petri Latvala wrote: On Tue, Nov 02, 2021 at 06:45:38PM -0700, John Harrison wrote: On 11/2/2021 16:34, Matthew Brost wrote: On Thu, Oct 21, 2021 at 04:40:40PM -0700, john.c.harri...@intel.com wrote: From: John Harrison Some of the capture tests were using explicit

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Split pre-skl primary plane update into noarm+arm pair

On Thu, Oct 21, 2021 at 12:27:57AM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Chop i9xx_plane_update() into two halves. Fist half becomes > the _noarm() variant, second part the _arm() variant. > > Fortunately I have already previously grouped the register > writes into roughtly the

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Fix up the sprite namespacing

On Mon, Oct 18, 2021 at 02:50:24PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Give all sprite exclusive functions/etc. a proper namespace. Reviewed-by: Stanislav Lisovskiy > > Cc: Stanislav Lisovskiy > Signed-off-by: Ville Syrjälä > --- >

Re: [Intel-gfx] [PATCH 4/9] drm/i915: Split update_plane() into update_noarm() + update_arm()

On Mon, Oct 18, 2021 at 02:50:25PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > The amount of plane registers we have to write has been steadily > increasing, putting more pressure on the vblank evasion mechanism > and forcing us to increase its time budget. Let's try to take some > of

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split pre-skl primary plane update into noarm+arm pair

On Mon, Oct 18, 2021 at 02:50:27PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Chop i9xx_plane_update() into two halves. Fist half becomes > the _noarm() variant, second part the _arm() variant. > > Fortunately I have already previously grouped the register > writes into roughtly the

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Split skl+ plane update into noarm+arm pair

On Mon, Oct 18, 2021 at 02:50:26PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Chop skl_program_plane() into two halves. Fist half becomes > the _noarm() variant, second part the _arm() variant. > > Fortunately I have already previously grouped the register > writes into roughtly the

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Split g4x+ sprite plane update into noarm+arm pair

On Mon, Oct 18, 2021 at 02:50:28PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Chop g4x_sprite_update() into two halves. Fist half becomes > the _noarm() variant, second part the _arm() variant. > > Fortunately I have already previously grouped the register > writes into roughtly the

Re: [Intel-gfx] [PATCH i-g-t 5/8] tests/i915/gem_exec_capture: Check for memory allocation failure

On 11/3/2021 07:00, Tvrtko Ursulin wrote: On 22/10/2021 00:40, john.c.harri...@intel.com wrote: From: John Harrison The sysfs file read helper does not actually report any errors if a realloc fails. It just silently returns a 'valid' but truncated buffer. This then leads to the decode of the

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Split ivb+ sprite plane update into noarm+arm pair

On Mon, Oct 18, 2021 at 02:50:29PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Chop ivb_sprite_update() into two halves. Fist half becomes > the _noarm() variant, second part the _arm() variant. > > Fortunately I have already previously grouped the register > writes into roughtly the

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Split vlv/chv sprite plane update into noarm+arm pair

On Mon, Oct 18, 2021 at 02:50:30PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Chop vlv_sprite_update() into two halves. Fist half becomes > the _noarm() variant, second part the _arm() variant. > > Fortunately I have already previously grouped the register > writes into roughtly the

Re: [Intel-gfx] [PATCH i-g-t 1/8] tests/i915/gem_exec_capture: Remove pointless assert

On 11/3/2021 06:50, Tvrtko Ursulin wrote: On 22/10/2021 00:40, john.c.harri...@intel.com wrote: From: John Harrison The 'many' test ended with an 'assert(count)', presumably meaning to ensure that some objects were actually captured. However, 'count' is the number of objects created not how

Re: [Intel-gfx] [PATCH v2 2/8] drm: improve drm_buddy_alloc function

On 25/10/2021 14:00, 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

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Fix async flip with decryption and/or DPT

On Mon, Oct 18, 2021 at 02:50:23PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We're currently forgetting to set the PLANE_SURF_DECRYPT > flag in the async flip path. So if the hardware were to > latch that bit despite this being an async flip we'd start > scanning out garbage. And if

Re: [Intel-gfx] [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate

On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote: > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote: > > --- a/drivers/gpu/drm/drm_edid.c > > +++ b/drivers/gpu/drm/drm_edid.c > > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct > > drm_connector

Re: [Intel-gfx] [PATCH v2 i-g-t 4/8] tests/i915/gem_exec_capture: Use contexts and engines properly

On Wed, Nov 03, 2021 at 10:04:45AM -0700, john.c.harri...@intel.com wrote: > From: John Harrison > > Some of the capture tests were using explicit contexts, some not. Some > were poking the per engine pre-emption timeout, some not. This would > lead to sporadic failures due to random timeouts,

[Intel-gfx] [PATCH v2 i-g-t 4/8] tests/i915/gem_exec_capture: Use contexts and engines properly

From: John Harrison Some of the capture tests were using explicit contexts, some not. Some were poking the per engine pre-emption timeout, some not. This would lead to sporadic failures due to random timeouts, contexts being banned depending upon how many subtests were run and/or how many

[Intel-gfx] [PATCH v2 i-g-t 8/8] tests/i915/gem_exec_capture: Update to support GuC based resets

From: John Harrison When GuC submission is enabled, GuC itself manages hang detection and recovery. Therefore, any test that relies on being able to trigger an engine reset in the driver will fail. Full GT resets can still be triggered by the driver. However, in that situation detecting the

[Intel-gfx] [PATCH v2 i-g-t 5/8] tests/i915/gem_exec_capture: Check for memory allocation failure

From: John Harrison The sysfs file read helper does not actually report any errors if a realloc fails. It just silently returns a 'valid' but truncated buffer. This then leads to the decode of the buffer failing in random ways. So, add a check for ENOMEM being generated during the read.

[Intel-gfx] [PATCH v2 i-g-t 7/8] lib/igt_gt: Allow per engine reset testing

From: John Harrison With GuC submission, engine resets are handled entirely within GuC rather than within i915. Traditionally, IGT has disallowed engine based resets becuase they don't send the uevent which IGT uses to check for unexpected resets. However, it is important to be able to test all

[Intel-gfx] [PATCH v2 i-g-t 1/8] tests/i915/gem_exec_capture: Remove pointless assert

From: John Harrison The 'many' test ended with an 'assert(count)', presumably meaning to ensure that some objects were actually captured. However, 'count' is the number of objects created not how many were captured. Plus, there is already a 'require(count > 1)' at the start and count is

[Intel-gfx] [PATCH v2 i-g-t 2/8] tests/i915/gem_exec_capture: Cope with larger page sizes

From: John Harrison At some point, larger than 4KB page sizes were added to the i915 driver. This included adding an informational line to the buffer entries in error capture logs. However, the error capture test was not updated to skip this string, thus it would silently abort processing.

[Intel-gfx] [PATCH v2 i-g-t 3/8] tests/i915/gem_exec_capture: Make the error decode a common helper

From: John Harrison The decode of the error capture contents was happening in two different sub-tests with two very different pieces of code. One being much more extensive than the other (actually decodes and verifies the contents of the captured buffers rather than just the address). So, move

[Intel-gfx] [PATCH v2 i-g-t 0/8] Fixes for gem_exec_capture

From: John Harrison Fix a bunch of issues with gem_exec_capture with the ultimate aim of making it pass on GuC enabled platforms. v2: Abstract the 'find first available engine' block into a helper (review feedback from Matthew B). Note that for unknown reasons, this helper does not work as a

[Intel-gfx] [PATCH v2 i-g-t 6/8] lib/igt_sysfs: Support large files

From: John Harrison The syfs helper functions were all using basic 'int' data types for sizs, offsets, etc. when reading from sysfs. This works fine for little files, but not for large error capture logs (which can be gigabytes in sizes). Signed-off-by: John Harrison Reviewed-by: Matthew Brost

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: fixup dma_fence_wait usage

We have a bug for the regression and I have updated the filter to include ICL and re-reported. https://gitlab.freedesktop.org/drm/intel/-/issues/2370 igt@kms_cursor_legacy@cursor-vs-flip-toggle - fail - Test assertion failure function cursor_vs_flip, Failed assertion: fail_count == 0, Failed to

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fixup dma_fence_wait usage

== Series Details == Series: drm/i915: fixup dma_fence_wait usage URL : https://patchwork.freedesktop.org/series/96504/ State : success == Summary == CI Bug Log - changes from CI_DRM_10828_full -> Patchwork_21505_full Summary ---

Re: [Intel-gfx] [RESEND PATCH 0/5] Cleanups for the nomodeset kernel command line parameter logic

Hello Thomas, On 11/3/21 14:01, Thomas Zimmermann wrote: [snip] >> >> >> Javier Martinez Canillas (5): >>drm/i915: Fix comment about modeset parameters >>drm: Move nomodeset kernel parameter handler to the DRM subsystem >>drm: Rename vgacon_text_force() function to

Re: [Intel-gfx] [RESEND PATCH 3/5] drm: Rename vgacon_text_force() function to drm_modeset_disabled()

On 11/3/21 13:57, Thomas Zimmermann wrote: [snip] >> >> -if (vgacon_text_force()) { >> +if (drm_modeset_disabled()) { >> DRM_ERROR("amdgpu kernel modesetting disabled.\n"); > > Please remove all such error messages from drivers. > drm_modeset_disabled() should print a

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Failsafe migration blits (rev5)

== Series Details == Series: drm/i915: Failsafe migration blits (rev5) URL : https://patchwork.freedesktop.org/series/95617/ State : success == Summary == CI Bug Log - changes from CI_DRM_10832_full -> Patchwork_21511_full Summary ---

Re: [Intel-gfx] [PATCH i-g-t 5/8] tests/i915/gem_exec_capture: Check for memory allocation failure

On 22/10/2021 00:40, john.c.harri...@intel.com wrote: From: John Harrison The sysfs file read helper does not actually report any errors if a realloc fails. It just silently returns a 'valid' but truncated buffer. This then leads to the decode of the buffer failing in random ways. So, add a

Re: [Intel-gfx] [PATCH i-g-t 1/8] tests/i915/gem_exec_capture: Remove pointless assert

On 22/10/2021 00:40, john.c.harri...@intel.com wrote: From: John Harrison The 'many' test ended with an 'assert(count)', presumably meaning to ensure that some objects were actually captured. However, 'count' is the number of objects created not how many were captured. Plus, there is already

Re: [Intel-gfx] [RESEND PATCH 1/5] drm/i915: Fix comment about modeset parameters

On Wed, 03 Nov 2021, Javier Martinez Canillas wrote: > The comment mentions that the KMS is enabled by default unless either the > i915.modeset module parameter or vga_text_mode_force boot option are used. > > But the latter does not exist and instead the nomodeset option was meant. > >

Re: [Intel-gfx] [RESEND PATCH 2/5] drm: Move nomodeset kernel parameter handler to the DRM subsystem

Hello Jani, On 11/3/21 13:56, Jani Nikula wrote: [snip] >> >> +obj-y += drm_nomodeset.o > > This is a subtle functional change. With this, you'll always have > __setup("nomodeset", text_mode) builtin and the parameter available. And > using nomodeset will print out the pr_warn() splat from

Re: [Intel-gfx] [RESEND PATCH 2/5] drm: Move nomodeset kernel parameter handler to the DRM subsystem

Hello Thomas, On 11/3/21 13:41, Thomas Zimmermann wrote: > Hi > > Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas: >> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver >> but the exported vgacon_text_force() symbol is only used by DRM drivers. >> >> It makes much

Re: [Intel-gfx] [RESEND PATCH 0/5] Cleanups for the nomodeset kernel command line parameter logic

Hi Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas: [ resend with all relevant people as Cc now, sorry to others for the spam ] There is a lot of historical baggage on this parameter. It's defined in the vgacon driver as a "nomodeset" parameter, but it's handler function is called

Re: [Intel-gfx] [RESEND PATCH 3/5] drm: Rename vgacon_text_force() function to drm_modeset_disabled()

Hi Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas: This function is used by some DRM drivers to determine if the "nomodeset" kernel command line parameter was set and prevent these drivers to probe. But the function name is quite confusing and does not reflect what really the drivers

Re: [Intel-gfx] [RESEND PATCH 2/5] drm: Move nomodeset kernel parameter handler to the DRM subsystem

On Wed, 03 Nov 2021, Javier Martinez Canillas wrote: > The "nomodeset" kernel cmdline parameter is handled by the vgacon driver > but the exported vgacon_text_force() symbol is only used by DRM drivers. > > It makes much more sense for the parameter logic to be in the subsystem > of the drivers

Re: [Intel-gfx] [RESEND PATCH 2/5] drm: Move nomodeset kernel parameter handler to the DRM subsystem

Hi Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas: The "nomodeset" kernel cmdline parameter is handled by the vgacon driver but the exported vgacon_text_force() symbol is only used by DRM drivers. It makes much more sense for the parameter logic to be in the subsystem of the drivers

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Failsafe migration blits (rev5)

== Series Details == Series: drm/i915: Failsafe migration blits (rev5) URL : https://patchwork.freedesktop.org/series/95617/ State : success == Summary == CI Bug Log - changes from CI_DRM_10832 -> Patchwork_21511 Summary ---

[Intel-gfx] [RESEND PATCH 2/5] drm: Move nomodeset kernel parameter handler to the DRM subsystem

The "nomodeset" kernel cmdline parameter is handled by the vgacon driver but the exported vgacon_text_force() symbol is only used by DRM drivers. It makes much more sense for the parameter logic to be in the subsystem of the drivers that are making use of it. Let's move that to DRM.

[Intel-gfx] [RESEND PATCH 3/5] drm: Rename vgacon_text_force() function to drm_modeset_disabled()

This function is used by some DRM drivers to determine if the "nomodeset" kernel command line parameter was set and prevent these drivers to probe. But the function name is quite confusing and does not reflect what really the drivers are testing when calling it. Use a better naming now that it is

[Intel-gfx] [RESEND PATCH 1/5] drm/i915: Fix comment about modeset parameters

The comment mentions that the KMS is enabled by default unless either the i915.modeset module parameter or vga_text_mode_force boot option are used. But the latter does not exist and instead the nomodeset option was meant. Signed-off-by: Javier Martinez Canillas ---

[Intel-gfx] [RESEND PATCH 0/5] Cleanups for the nomodeset kernel command line parameter logic

[ resend with all relevant people as Cc now, sorry to others for the spam ] There is a lot of historical baggage on this parameter. It's defined in the vgacon driver as a "nomodeset" parameter, but it's handler function is called text_mode() that sets a variable named vgacon_text_mode_force whose

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Failsafe migration blits (rev5)

== Series Details == Series: drm/i915: Failsafe migration blits (rev5) URL : https://patchwork.freedesktop.org/series/95617/ State : warning == Summary == $ dim checkpatch origin/drm-tip b899c699aca8 drm/i915/ttm: Reorganize the ttm move code -:511: WARNING:FILE_PATH_CHANGES: added, moved or

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: For PCON TMDS mode set only the relavant bits in config DPCD

> -Original Message- > From: Nautiyal, Ankit K > Sent: Friday, October 29, 2021 11:32 AM > To: intel-gfx@lists.freedesktop.org > Cc: Sharma, Swati2 ; Shankar, Uma > > Subject: [PATCH 2/2] drm/i915/dp: For PCON TMDS mode set only the relavant > bits > in config DPCD > > Currently we

[Intel-gfx] [PATCH v4 2/2] drm/i915/ttm: Failsafe migration blits

If the initial fill blit or copy blit of an object fails, the old content of the data might be exposed and read as soon as either CPU- or GPU PTEs are set up to point at the pages. Intercept the blit fence with an async callback that checks the blit fence for errors and if there are errors

[Intel-gfx] [PATCH v4 1/2] drm/i915/ttm: Reorganize the ttm move code

We are about to introduce failsafe- and asynchronous migration and ttm moves. This will add complexity and code to the TTM move code so it makes sense to split it out to a separate file to make the i915 TTM code easer to digest. Split the i915 TTM move code out and since we will have to change the

[Intel-gfx] [PATCH v4 0/2] drm/i915: Failsafe migration blits

This patch series introduces failsafe migration blits. The reason for this seemingly strange concept is that if the initial clearing or readback of LMEM fails for some reason[1], and we then set up either GPU- or CPU ptes to the allocated LMEM, we can expose old contents from other clients. So

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dp: Optimize the FRL configuration for HDMI2.1 PCON

> -Original Message- > From: Nautiyal, Ankit K > Sent: Friday, October 29, 2021 11:32 AM > To: intel-gfx@lists.freedesktop.org > Cc: Sharma, Swati2 ; Shankar, Uma > > Subject: [PATCH 1/2] drm/i915/dp: Optimize the FRL configuration for HDMI2.1 > PCON > > Currently the HDMI2.1 PCON's

Re: [Intel-gfx] [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate

On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote: > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct > drm_connector *connector, > u32 max_tmds_clock = hf_vsdb[5] * 5000; >

Re: [Intel-gfx] [PATCH i-g-t 4/8] tests/i915/gem_exec_capture: Use contexts and engines properly

On Tue, Nov 02, 2021 at 06:45:38PM -0700, John Harrison wrote: > On 11/2/2021 16:34, Matthew Brost wrote: > > On Thu, Oct 21, 2021 at 04:40:40PM -0700, john.c.harri...@intel.com wrote: > > > From: John Harrison > > > > > > Some of the capture tests were using explicit contexts, some not. Some >

Re: [Intel-gfx] [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate

On 02/11/2021 15:59, Maxime Ripard wrote: > A lot of drivers open-code the HDMI 1.4 maximum pixel rate in their > driver to test whether the resolutions are supported or if the > scrambling needs to be enabled. > > Let's create a common define for everyone to use it. > > Cc: Alex Deucher > Cc:

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: fixup dma_fence_wait usage

On 02/11/2021 18:48, Patchwork wrote: *Patch Details* *Series:* drm/i915: fixup dma_fence_wait usage *URL:* https://patchwork.freedesktop.org/series/96504/ *State:*failure *Details:*

Re: [Intel-gfx] [PATCH 28/29] drm/i915/gvt: convert to use vfio_register_group_dev()

On Tue, Nov 02, 2021 at 01:41:36PM -0300, Jason Gunthorpe wrote: > On Tue, Nov 02, 2021 at 08:06:00AM +0100, Christoph Hellwig wrote: > > This is straightforward conversion, the intel_vgpu already has a pointer > > to the vfio_dev, which can be replaced with the embedded structure and > > we can