On Thu, 2024-03-21 at 14:38 +0200, Jani Nikula wrote:
> On Wed, 20 Mar 2024, José Roberto de Souza wrote:
> > It is misleading, if the intention was to also print something
> > in case it succeed it should have a different string.
> >
> > Cc: Alan Previn
> > Signed-off-by: José Roberto de Souza
On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> AuxCCS framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. FlatCCS framebuffers
> work and they are left enabled. CCS is left untouched for i915
> driver.
>
Fixes: 44e694958b95 ("dr
On Thu, 2024-02-29 at 16:44 +, Souza, Jose wrote:
> On Wed, 2024-02-28 at 06:04 -0800, José Roberto de Souza wrote:
> > On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> > > AuxCCS framebuffers don't work on Xe driver hence disable them
> > > fr
On Wed, 2024-02-28 at 06:04 -0800, José Roberto de Souza wrote:
> On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> > AuxCCS framebuffers don't work on Xe driver hence disable them
> > from plane capabilities until they are fixed. FlatCCS framebuffers
> > work and they are left enable
On Wed, 2024-02-28 at 16:02 +0200, Juha-Pekka Heikkila wrote:
> AuxCCS framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. FlatCCS framebuffers
> work and they are left enabled. CCS is left untouched for i915
> driver.
>
Reviewed-by: José Robert
On Mon, 2024-02-19 at 13:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tooling appears very strict so lets pacify it by adding some comments,
> even if fields are completely self-explanatory.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Tvrtko Ursulin
> Fixes: b11236486
On Fri, 2024-02-09 at 09:06 +, Tvrtko Ursulin wrote:
> On 08/02/2024 17:55, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> > > On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > > > On 08/02/2024 14:30, Souza
On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > On 08/02/2024 14:30, Souza, Jose wrote:
> > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
>
On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> On 08/02/2024 14:30, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Add a new query to the GuC submission interface version.
&
On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Add a new query to the GuC submission interface version.
>
> Mesa intends to use this information to check for old firmware versions
> with a known bug where using the render and compute command streamers
> simul
On Wed, 2024-02-07 at 11:52 -0800, John Harrison wrote:
> On 2/7/2024 11:43, Souza, Jose wrote:
> > On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> > > On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > > > On 07/02/2024 18:12, John Harrison wrote:
> > >
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > On 07/02/2024 18:12, John Harrison wrote:
> > > On 2/7/2024 03:56, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > Add a new query to the GuC submission interface version.
> >
On Wed, 2024-02-07 at 13:36 +0200, Joonas Lahtinen wrote:
> Quoting Tvrtko Ursulin (2024-02-07 10:44:01)
> >
> > On 06/02/2024 20:51, Souza, Jose wrote:
> > > On Tue, 2024-02-06 at 12:42 -0800, John Harrison wrote:
> > > > On 2/6/2024 08:33, Tvrtko Ursulin
On Tue, 2024-02-06 at 12:42 -0800, John Harrison wrote:
> On 2/6/2024 08:33, Tvrtko Ursulin wrote:
> > On 01/02/2024 18:25, Souza, Jose wrote:
> > > On Wed, 2024-01-24 at 08:55 +, Tvrtko Ursulin wrote:
> > > > On 24/01/2024 08:19, Joonas Lahtinen wrote:
>
On Thu, 2024-01-25 at 08:07 -0800, José Roberto de Souza wrote:
> On Thu, 2024-01-25 at 17:56 +0200, Juha-Pekka Heikkila wrote:
> > On 25.1.2024 17.28, Souza, Jose wrote:
> > > On Thu, 2024-01-25 at 17:25 +0200, Juha-Pekka Heikkila wrote:
> > > > AuxCCS framebuffers
On Wed, 2024-01-24 at 08:55 +, Tvrtko Ursulin wrote:
> On 24/01/2024 08:19, Joonas Lahtinen wrote:
> > Add reporting of the GuC submissio/VF interface version via GETPARAM
> > properties. Mesa intends to use this information to check for old
> > firmware versions with known bugs before enabling
On Thu, 2024-01-25 at 17:56 +0200, Juha-Pekka Heikkila wrote:
> On 25.1.2024 17.28, Souza, Jose wrote:
> > On Thu, 2024-01-25 at 17:25 +0200, Juha-Pekka Heikkila wrote:
> > > AuxCCS framebuffers don't work on Xe driver hence disable them
> > > from plane capabiliti
On Thu, 2024-01-25 at 17:25 +0200, Juha-Pekka Heikkila wrote:
> AuxCCS framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. FlatCCS framebuffers
> work and they are left enabled. CCS is left untouched for i915
> deriver.
>
> Closes: https://gitlab
On Wed, 2024-01-24 at 10:19 +0200, Joonas Lahtinen wrote:
> Add reporting of the GuC submissio/VF interface version via GETPARAM
> properties. Mesa intends to use this information to check for old
> firmware versions with known bugs before enabling features like async
> compute.
>
Reviewed-by: Jo
On Mon, 2024-01-08 at 17:18 -0500, Rodrigo Vivi wrote:
> On Tue, Jan 02, 2024 at 09:44:48PM +0200, Jani Nikula wrote:
> > On Tue, 02 Jan 2024, Juha-Pekka Heikkila
> > wrote:
> > > Aux ccs framebuffers don't work on Xe driver hence disable them
> > > from plane capabilities until they are fixed. F
On Tue, 2024-01-02 at 20:24 +0200, Juha-Pekka Heikkila wrote:
> Aux ccs framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. Flat ccs framebuffers
> work and they are left enabled. Here is separated plane capabilities
> check on i915 so it can beha
On Wed, 2024-01-03 at 17:37 +0200, Jani Nikula wrote:
> On Wed, 03 Jan 2024, José Roberto de Souza wrote:
> > Often getting DBS overflows when starting Xorg or Wayland compositor
> > when running Xe KMD.
> > Issue was reported but nothing was done, so disabling DSB as whole
> > until properly fixe
On Fri, 2023-11-17 at 15:48 -0500, Rodrigo Vivi wrote:
> Let's respect Documentation/process/botching-up-ioctls.rst
> and add the proper padding for a 64b alignment with all as
> well as all the required checks and settings for the pads
> and the reserved entries.
>
> v2: Fix remaining wholes and
On Wed, 2023-06-21 at 13:48 +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_cursor.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/d
On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > > On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> > > > Because of the additional f
On Fri, 2023-04-21 at 02:02 +, Patchwork wrote:
Patch Details
Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev4)
URL:https://patchwork.freedesktop.org/series/116325/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/index.
On Thu, 2023-04-20 at 09:35 -0700, Lucas De Marchi wrote:
> On Thu, Apr 20, 2023 at 08:36:37AM -0700, Jose Souza wrote:
> > On Thu, 2023-04-20 at 11:27 -0400, Rodrigo Vivi wrote:
> > > On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> > > > On Wed, 2023-
On Thu, 2023-04-20 at 11:27 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> > On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> > > On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > > > On Tue, 18 Ap
On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > On Tue, 18 Apr 2023, Lucas De Marchi wrote:
> > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Sou
On Tue, 2023-04-11 at 14:20 -0700, Lucas De Marchi wrote:
> On Tue, Apr 11, 2023 at 08:07:12PM +, Jose Souza wrote:
> > On Tue, 2023-04-11 at 12:59 -0700, Lucas De Marchi wrote:
> > > On Tue, Apr 11, 2023 at 10:51:04AM -0400, Rodrigo Vivi wrote:
> > > > On Tue, Apr 11, 2023 at 12:14:36PM +0300,
On Tue, 2023-04-11 at 12:59 -0700, Lucas De Marchi wrote:
> On Tue, Apr 11, 2023 at 10:51:04AM -0400, Rodrigo Vivi wrote:
> > On Tue, Apr 11, 2023 at 12:14:36PM +0300, Jani Nikula wrote:
> > > On Tue, 11 Apr 2023, Ville Syrjälä wrote:
> > > > On Tue, Apr 11, 2023 at 11:51:33AM +0300, Jani Nikula w
On Tue, 2023-04-11 at 11:33 +0300, Jani Nikula wrote:
> On Tue, 11 Apr 2023, Jani Nikula wrote:
> > On Mon, 10 Apr 2023, José Roberto de Souza wrote:
> > > Start to move the initialization of some lock from
> > > i915_driver_early_probe().
> >
> > Please send this as standalone patch to i915. It
On Mon, 2023-04-10 at 11:37 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 06, 2023 at 07:31:30AM -0700, José Roberto de Souza wrote:
> > This spin lock will not be used in older display versions, so no need
> > to initialize it.
>
> Should we add some warn_on(disp_ver < 12) on the dkl phy functions?
I
On Mon, 2023-04-10 at 11:33 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 06, 2023 at 07:31:29AM -0700, José Roberto de Souza wrote:
> > Start to move the initialization of some lock from
> > i915_driver_early_probe().
> > This will also fix a warning in Xe kmd:
> >
> > [ 201.894839] xe :00:02.0:
On Thu, 2023-04-06 at 16:38 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 06, 2023 at 07:31:28AM -0700, José Roberto de Souza wrote:
> > dsparb_lock it not used anymore, nuke it.
>
> Well, this doesn't exist in our drm-tip baseline, so it would be good
> if this patch is a fixup! to whatever patch is a
On Mon, 2023-04-03 at 13:03 -0400, Rodrigo Vivi wrote:
> On Mon, Apr 03, 2023 at 09:46:11AM -0700, José Roberto de Souza wrote:
> > No behavior changes here, just adding a function to make clear
> > what locks initialized here are display related or not.
> >
> > Cc: intel-gfx@lists.freedesktop.org
On Thu, 2023-03-16 at 15:17 +0200, Imre Deak wrote:
> The commit renaming icl_tc_phy_is_in_safe_mode() to
> icl_tc_phy_take_ownership() didn't flip the function's return value
> accordingly, fix this up.
>
> This didn't cause an actual problem besides state check errors, since
> the function is on
On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
> As a fallback if we decide not to merge the frontbuffer tracking, allow
> i915 to keep its own implementation, and do the right thing in Xe.
>
> The frontbuffer tracking for Xe is still done per-fb, while i915 can
> keep doing the weird
On Mon, 2023-02-06 at 08:59 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Add another EHL pci id
> URL: https://patchwork.freedesktop.org/series/113691/
> State: success
Pushed, thanks for the patch.
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113691v1/index.htm
On Mon, 2023-02-06 at 15:37 +1100, Jonathan Gray wrote:
> described as "32 Execution Unit (EU) Super SKU" in:
> Intel Atom x6000E Series, and Intel Pentium and Celeron N and
> J Series Processors for IoT Applications
> Datasheet, Volume 1
> Document Number: 636112-1.6
>
Reviewed-by: José Roberto
On Fri, 2023-01-27 at 10:27 +0200, Jouni Högander wrote:
> SEL_FETCH_CTL registers are armed immediately when plane is disabled.
> SEL_FETCH_* instances of plane configuration are used when doing
> selective update and normal plane register instances for full updates.
> Currently all SEL_FETCH_* re
On Tue, 2022-11-29 at 09:51 +0200, Jouni Högander wrote:
> Currently we are observing occasionally display flickering or complete
> freeze. This is narrowed down to be caused by single full frame update
> (SFF).
>
> SFF bit after it's written gets cleared by HW in subsequent vblank
> i.e. when the
On Mon, 2022-11-21 at 14:31 +, Patchwork wrote:
Patch Details
Series: drm/i915/gsc: Only initialize GSC in tile 0 (rev2)
URL:https://patchwork.freedesktop.org/series/110304/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110304v2/index.html
CI Bug Log -
On Wed, 2022-11-02 at 19:45 +0200, Jouni Högander wrote:
> Selective update area is now aligned with DSC slice height when
> DSC is enabled. Remove inappropriate warning about missing DSC
> alignment.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
>
> Fixe
On Wed, 2022-11-02 at 19:45 +0200, Jouni Högander wrote:
> Do not enable psr2 if panel ganularity is not aligned with DSC slice
> height when DSC is enabled
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Cc: Mika Kahola
>
> Signed-off-by: Jouni Högander
> ---
> drivers/
On Tue, 2022-11-01 at 20:55 +, Hogander, Jouni wrote:
> On Tue, 2022-11-01 at 20:00 +0000, Souza, Jose wrote:
> > On Fri, 2022-10-21 at 08:49 +0300, Jouni Högander wrote:
> > > Selective update area is now aligned with DSC slice height when
> > > DSC is enabled. R
On Fri, 2022-10-21 at 08:49 +0300, Jouni Högander wrote:
> Selective update area is now aligned with DSC slice height when
> DSC is enabled. Remove inappropriate warning about missing DSC
> alignment.
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
>
> Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend
On Tue, 2022-11-01 at 13:53 +0200, Jouni Högander wrote:
> MTL shares PSR2_MAN_TRK_CTL bits with ADL. Currently some bit
> getter functions are incorrect for MTL. This patch fixes those.
>
> Bspec: 49274
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
> Cc:
On Mon, 2022-10-24 at 08:46 +0300, Jouni Högander wrote:
> Currently we are observing mouse cursor stuttering when using
> xrandr --scaling=1.2x1.2. X scaling/transformation seems to be
> doing fronbuffer rendering. When moving mouse cursor X seems to
> perform several invalidates and only one Dirt
On Mon, 2022-10-17 at 20:05 +, Patchwork wrote:
Patch Details
Series: drm/i915: Extend Wa_1607297627 to Alderlake-P
URL:https://patchwork.freedesktop.org/series/109772/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/index.html
CI Bug Log - chang
On Mon, 2022-10-17 at 09:51 +0100, Tvrtko Ursulin wrote:
> On 14/10/2022 23:08, Lucas De Marchi wrote:
> > On Thu, Oct 13, 2022 at 06:23:07PM +, Jose Souza wrote:
> > > missed the "drm/" in the subject 😛
> >
> > with that, Reviewed-by: Lucas De Marchi
>
> And where is the commit text? :p
>
missed the "drm/" in the subject 😛
On Thu, 2022-10-13 at 11:14 -0700, José Roberto de Souza wrote:
> BSpec: 54369
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/d
On Mon, 2022-10-03 at 09:30 +, Patchwork wrote:
Patch Details
Series: drm/i915/psr: Fix PSR_IMR/IIR field handling (rev4)
URL:https://patchwork.freedesktop.org/series/108811/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108811v4/index.html
CI Bug Log -
On Mon, 2022-10-03 at 10:20 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
>
> /*
> * gen12+ has registers relative to transcoder and one per transcoder
> * using the same bit definition: handle it as TRANSC
On Thu, 2022-09-29 at 06:16 -0700, José Roberto de Souza wrote:
> On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> > bits in PSR_IMR/IIR registers:
> >
> > /*
> > * gen12+ has registers relative to transcoder an
On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
>
> /*
> * gen12+ has registers relative to transcoder and one per transcoder
> * using the same bit definition: handle it as TRANSC
On Fri, 2022-09-23 at 12:45 +, Hogander, Jouni wrote:
> On Fri, 2022-09-23 at 12:37 +0000, Souza, Jose wrote:
> > On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> > > On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > > > On Thu, 2022-09-22
On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> On Thu, 2022-09-22 at 13:08 +0000, Souza, Jose wrote:
> > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift
> > > for
> >
On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
>
> /*
> * gen12+ has registers relative to transcoder and one per transcoder
> * using the same bit definition: handle it as TRANSC
On Wed, 2022-09-21 at 09:24 +0300, Jouni Högander wrote:
> Current PSR code is assuming TRANSCODER_EDP == 0. This is not the case
> and all fields in PSR_IMR and PSR_IIR are shifted incorrectly if
> DISPLAY_VER >= 12.
There is no EDP transcoder in display 12 and newer.
>
> Fix this by using TRAN
On Fri, 2022-09-16 at 14:08 +0300, Jouni Högander wrote:
> If there is a PSR aux error sink is marked as not reliable
> and PSR is permantently disabled.
>
> Current code is activating PSR again even there was PSR aux error.
> Fix this by skipping intel_psr_activate when PSR aux error is
> detecte
On Fri, 2022-07-15 at 11:39 +0300, Lisovskiy, Stanislav wrote:
> On Fri, Jul 15, 2022 at 08:33:43AM +0300, Hogander, Jouni wrote:
> > On Thu, 2022-07-14 at 08:07 -0700, José Roberto de Souza wrote:
> > > The issue here was on for_each_intel_encoder_mask_with_psr() over the
> > > new_crtc_state enco
On Thu, 2022-07-14 at 07:22 +, Hogander, Jouni wrote:
> On Wed, 2022-07-13 at 21:04 +0000, Souza, Jose wrote:
> > On Wed, 2022-07-13 at 20:58 +0000, Souza, Jose wrote:
> > > On Mon, 2022-07-11 at 14:17 +0300, Jouni Högander wrote:
> > > > Currently PSR is le
On Wed, 2022-07-13 at 20:58 +, Souza, Jose wrote:
> On Mon, 2022-07-11 at 14:17 +0300, Jouni Högander wrote:
> > Currently PSR is left enabled when all planes are disabled if there
> > is no attached encoder in new state. This seems to be causing FIFO
> > underruns.
>
On Mon, 2022-07-11 at 14:17 +0300, Jouni Högander wrote:
> Currently PSR is left enabled when all planes are disabled if there
> is no attached encoder in new state. This seems to be causing FIFO
> underruns.
What is the case were there is no attached encoder and active_planes > 0?
>
> Fix this
Hi Hangyu
Don't know why but our CI still did not caught this patch.
Maybe it is because intel-gfx@lists.freedesktop.org needs to be in the "to"
list, try that in future patches.
Anyways I have resend it and it is properly behaving now.
https://patchwork.freedesktop.org/series/105601/
After CI
On Fri, 2022-06-24 at 09:39 +0300, Dan Carpenter wrote:
> This function is supposed to return zero or negative error codes but it
> accidentally returns true on failure.
Reviewed-by: José Roberto de Souza
>
> Fixes: 92a020747d6c ("drm/i915: Split shared dpll .get_dplls() into compute
> and get
On Wed, 2022-06-22 at 15:19 -0700, Matt Roper wrote:
> On Tue, Jun 21, 2022 at 10:03:04AM -0700, Souza, Jose wrote:
> > On Fri, 2022-06-17 at 12:28 -0700, Matt Roper wrote:
> > > On Fri, Jun 17, 2022 at 12:06:29PM -0700, José Roberto de Souza wrote:
> > > > Gem bu
On Thu, 2022-06-23 at 13:44 +, Souza, Jose wrote:
> On Mon, 2022-05-16 at 15:19 +0800, Hangyu Hua wrote:
> > If drm_connector_init fails, intel_connector_free will be called to take
> > care of proper free. So it is necessary to drop the refcount of port
> > before
On Mon, 2022-05-16 at 15:19 +0800, Hangyu Hua wrote:
> If drm_connector_init fails, intel_connector_free will be called to take
> care of proper free. So it is necessary to drop the refcount of port
> before intel_connector_free.
Reviewed-by: José Roberto de Souza
>
> Fixes: 091a4f91942a ("dr
On Fri, 2022-06-17 at 12:28 -0700, Matt Roper wrote:
> On Fri, Jun 17, 2022 at 12:06:29PM -0700, José Roberto de Souza wrote:
> > Gem buffers could still be in use by display after i915_gem_suspend()
> > is executed so there is chances that i915_gem_flush_free_objects()
> > will be being executed a
On Mon, 2022-06-13 at 09:53 -0700, Matt Roper wrote:
> As with past platforms, the bspec's performance tuning guide provides
> recommended MMIO settings. Although not technically "workarounds" we
> apply these through the workaround framework to ensure that they're
> re-applied at the proper times
On Thu, 2022-06-09 at 17:01 +, Patchwork wrote:
Patch Details
Series: drm/i915/display: Fix handling of enable_psr parameter
URL:https://patchwork.freedesktop.org/series/104907/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104907v1/index.html
CI Bug Lo
On Tue, 2022-06-07 at 13:05 +, Hogander, Jouni wrote:
> On Tue, 2022-06-07 at 10:36 +0300, Jani Nikula wrote:
> > On Mon, 06 Jun 2022, "Souza, Jose" wrote:
> > > On Mon, 2022-06-06 at 11:16 +0300, Jani Nikula wrote:
> > > > On Mon, 06 Jun 2022, "
On Mon, 2022-06-06 at 11:16 +0300, Jani Nikula wrote:
> On Mon, 06 Jun 2022, "Hogander, Jouni" wrote:
> > On Fri, 2022-06-03 at 16:32 +, Souza, Jose wrote:
> > > On Fri, 2022-06-03 at 13:14 +, Hogander, Jouni wrote:
> > > > On Fri, 2022
Hi Lakshmi
Can you please help with this failures?
Current code is only doing a small change that would only affect DG2.
On Fri, 2022-06-03 at 20:09 +, Patchwork wrote:
Patch Details
Series: drm/i915/display/fbc: Do not apply WA 22014263786 to DG2 (rev2)
URL:https://patchwork.freedesktop.
On Fri, 2022-06-03 at 13:14 +, Hogander, Jouni wrote:
> On Fri, 2022-06-03 at 15:43 +0300, Jani Nikula wrote:
> > On Fri, 03 Jun 2022, Jouni Högander wrote:
> > > Export headless sku bit (bit 13) from opregion->header->pcon as an
> > > interface to check if our device is headless configuration
On Thu, 2022-06-02 at 16:30 -0700, Matt Roper wrote:
> We missed this setting in the initial device info patch's definition of
> XE_HPC_FEATURES.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
On Wed, 2022-06-01 at 14:06 -0700, Matt Roper wrote:
> From: Stuart Summers
>
> Our internal teams have identified a few additional engine registers
> that are worth inspecting in error state dumps during development &
> debug. Let's capture and print them as part of our error dump.
>
> For sim
On Thu, 2022-05-19 at 12:17 +, Hogander, Jouni wrote:
> On Wed, 2022-05-18 at 20:00 +0000, Souza, Jose wrote:
> > On Wed, 2022-05-18 at 10:45 +0300, Jouni Högander wrote:
> > > Currently there is no mean to get understanding how psr is
> > > utilized.
> >
On Wed, 2022-05-18 at 10:45 +0300, Jouni Högander wrote:
> Currently there is no mean to get understanding how psr is utilized.
> E.g. How much psr is actually enabled or how often driver falls back
> to full update.
But with this information what can you do?
I don't see much value on it.
We have
On Fri, 2022-05-13 at 17:28 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails. For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
>
> One of such for example is b
On Fri, 2022-05-13 at 15:30 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
>
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
>
> v2: Set x1 and x2 in d
On Fri, 2022-05-13 at 15:30 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails. For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
>
> One of such for example is b
On Wed, 2022-05-11 at 08:39 +0100, Tvrtko Ursulin wrote:
> On 10/05/2022 08:41, Jani Nikula wrote:
> > On Tue, 10 May 2022, Joonas Lahtinen
> > wrote:
> > > Quoting Souza, Jose (2022-05-09 17:19:28)
> > > > On Mon, 2022-05-09 at 15:38 +0300, Joonas Lahtinen w
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Add drm_debug_once* macros to allow printing out one time debug
> messages which can be still controlled via drm.debug parameter.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
> Cc: Mark Pearson
>
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
>
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
>
> v2: Set x1 and x2 in d
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails. For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
>
> One of such for example is b
On Mon, 2022-05-09 at 15:52 +0100, Matthew Auld wrote:
> On Mon, 9 May 2022 at 15:05, Souza, Jose wrote:
> >
> > On Mon, 2022-05-09 at 12:09 +0100, Matthew Auld wrote:
> > > On Sat, 7 May 2022 at 14:29, José Roberto de Souza
> > > wrote:
> > > >
On Mon, 2022-05-09 at 15:27 +0100, Tvrtko Ursulin wrote:
> On 09/05/2022 15:01, Souza, Jose wrote:
> > On Mon, 2022-05-09 at 14:32 +0100, Tvrtko Ursulin wrote:
> > > On 05/05/2022 20:35, José Roberto de Souza wrote:
> > > > No need to have this parameter in intel_dev
On Mon, 2022-05-09 at 17:05 +0300, Jani Nikula wrote:
> On Mon, 09 May 2022, Tvrtko Ursulin wrote:
> > On 05/05/2022 20:35, José Roberto de Souza wrote:
> > > No need to have this parameter in intel_device_info struct
> > > as all platforms with display version 9 or newer, haswell or broadwell
> >
On Mon, 2022-05-09 at 15:38 +0300, Joonas Lahtinen wrote:
> Quoting José Roberto de Souza (2022-05-07 16:28:50)
> > No need to have this parameter in intel_device_info struct
> > as this feature is supported by Broadwell, Haswell all platforms with
> > display version 9 or newer.
>
> This is oppos
On Mon, 2022-05-09 at 12:09 +0100, Matthew Auld wrote:
> On Sat, 7 May 2022 at 14:29, José Roberto de Souza
> wrote:
> >
> > This feature is supported in graphics version 6 and newer in all
> > integrated GPUs not including VLC and CHV, so we can drop this flag
> > for a not so complicated macro
On Mon, 2022-05-09 at 14:32 +0100, Tvrtko Ursulin wrote:
> On 05/05/2022 20:35, José Roberto de Souza wrote:
> > No need to have this parameter in intel_device_info struct
> > as all platforms with display version 9 or newer, haswell or broadwell
> > supports it.
> >
> > As a side effect of the of
On Mon, 2022-05-09 at 10:24 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
>
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
>
> v2: Set x1 and x2 in d
On Mon, 2022-05-09 at 10:24 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails. For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
>
> One of such for example is b
On Fri, 2022-05-06 at 18:28 +, Hogander, Jouni wrote:
> On Fri, 2022-05-06 at 15:29 +0000, Souza, Jose wrote:
> > On Fri, 2022-05-06 at 08:48 +0300, Jouni Högander wrote:
> > > Currently we have some corner cases where area calculation
> > > fails. For
> >
On Fri, 2022-05-06 at 08:48 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
>
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
>
> Closes: https://gitlab
On Fri, 2022-05-06 at 08:48 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails. For
> these sel fetch are calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
Aren't you able to reproduce this
On Thu, 2022-05-05 at 00:33 +0300, Ville Syrjälä wrote:
> On Wed, May 04, 2022 at 12:07:45PM -0700, José Roberto de Souza wrote:
> > This feature is supported from display 9 to display 12 and was
> > incorrectly being applied to DG2 and Alderlake-P.
>
> They just renamed the register to ARB_HP_CTL
1 - 100 of 1062 matches
Mail list logo
