On Tue, 2024-04-23 at 10:40 +0300, Govindapillai, Vinod wrote:
> On Fri, 2024-04-19 at 20:19 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 05, 2024 at 02:35:33PM +0300, Vinod Govindapillai wrote:
> > > The current intel_bw_atomic_check do not check the possbility
> > > of
On Fri, 2024-04-19 at 20:19 +0300, Ville Syrjälä wrote:
> On Fri, Apr 05, 2024 at 02:35:33PM +0300, Vinod Govindapillai wrote:
> > The current intel_bw_atomic_check do not check the possbility
> > of a sagv configuration change after the hw state readout.
> > Hence cannot update the sagv
On Fri, 2024-04-19 at 08:42 +, Hogander, Jouni wrote:
> On Fri, 2024-04-05 at 14:35 +0300, Vinod Govindapillai wrote:
> > We have couple of customer issues, related to SAGV/QGV point
> > calculation. Those patches contain fixes plus some additional
> > debugs for those issues.
>
> For the
+Jani
On Tue, 2024-04-09 at 12:36 +0300, Vinod Govindapillai wrote:
> From: Lu Baolu
>
> Commit 1a75cc710b95 ("iommu/vt-d: Use rbtree to track iommu probed
> devices") adds all devices probed by the iommu driver in a rbtree
> indexed by the source ID of each device. It assumes that each device
On Mon, 2024-04-08 at 11:32 +0300, Lisovskiy, Stanislav wrote:
> On Fri, Apr 05, 2024 at 02:35:29PM +0300, Vinod Govindapillai wrote:
> > From: Stanislav Lisovskiy
> >
> > We need that in order to force disable SAGV in next patch.
> > Also it is beneficial to separate that code, as in majority
On Mon, 2024-04-08 at 11:29 +0300, Lisovskiy, Stanislav wrote:
> On Fri, Apr 05, 2024 at 02:35:32PM +0300, Vinod Govindapillai wrote:
> > From: Stanislav Lisovskiy
> >
> > There could be multiple qgv and psf gv points with similar values.
> > Apparently pcode's handling og psf and qgv points are
Hi Ville,
Regarding the patch 5/6 in this series, I have asked the pcode team for
clarifications on how to
handle cases with duplicate QGV points.
Please note that I added a new patch to force the QGV check after HW state
readout (patch 6/6)
without that we won't be updating the QGV unless
Hi Ville,
On Mon, 2024-03-25 at 17:03 +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 03:01:56PM +0200, Vinod Govindapillai wrote:
> > From: Stanislav Lisovskiy
> >
> > There could be multiple qgv and psf gv points with similar values
> > In case if we need to set one such QGV or psf gv
Hi Stan
On Tue, 2024-02-20 at 11:31 +0200, Stanislav Lisovskiy wrote:
> Problem is that on some platforms, we do get QGV point mask in wrong
> state on boot. However driver assumes it is set to 0
> (i.e all points allowed), however in reality we might get them all restricted,
> causing issues.
>
Hi Stan.
On Tue, 2024-02-20 at 11:31 +0200, Stanislav Lisovskiy wrote:
> We need that in order to force disable SAGV in next patch.
> Also it is beneficial to separate that code, as in majority cases,
> when SAGV is enabled, we don't even need those calculations.
> Also we probably need to
Hi Stan
On Tue, 2024-02-20 at 11:31 +0200, Stanislav Lisovskiy wrote:
> For debug purposes we need those - error path won't flood the log,
> however there has been already numerous cases, when due to lack
> of debugs, we couldn't immediately tell what was the problem on
> customer machine, which
Hi.
On Thu, 2024-02-22 at 13:04 -0300, Gustavo Sousa wrote:
> Hi, guys.
>
> (This is a re-send, because I *think* my MUA badly formed the address to
> the mailing list.)
>
> Quoting Govindapillai, Vinod (2024-02-22 11:39:32-03:00)
> > Hi,
> >
> >
Hi,
Well.. sorry.. I didn't know Gustavo is already working on this!
@Gustavo, pls ignore this series if you are arealdy working on this. Please let
me know
On Thu, 2024-02-22 at 08:02 -0600, Lucas De Marchi wrote:
> +Gustavo as he was looking at upstreaming these patches.
>
> Were the issues
On Mon, 2024-02-19 at 12:06 +0530, Suraj Kandpal wrote:
> If fixed refresh rate program the PKGC_LATENCY register
> with the highest latency from level 1 and above LP registers
> and program ADDED_WAKE_TIME = DSB execution time.
> else program PKGC_LATENCY with all 1's and ADDED_WAKE_TIME as 0.
>
Hi Suraj,
+Ville - please comment if you see anything wrong with my explanation here
I think there could be a problem with the current logic and a possibility for
underrun. As per the
bspec we need to configure highest latency to soc.
As per this patch, skl_program_dpkgc_latency() is called
On Tue, 2024-01-23 at 11:00 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No point in wasting a fence on a plane if it can't do FBC anyway.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Suraj,
On Mon, 2024-02-05 at 13:31 +0530, Suraj Kandpal wrote:
> Program the PKGC_LATENCY register with the highest latency from
> level 1 and above LP registers else program with all 1's.
> This is used to improve package C residency by sending the highest
> latency tolerance requirement
On Thu, 2024-02-01 at 14:21 +0530, Suraj Kandpal wrote:
> Add the register that needs to read and written onto for
> deep pkgc programming.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/skl_watermark_regs.h | 4
> 1 file changed, 4 insertions(+)
Reviewed-by: Vinod
On Thu, 2024-01-11 at 15:59 +0200, Ville Syrjälä wrote:
> On Thu, Jan 11, 2024 at 01:47:02PM +0000, Govindapillai, Vinod wrote:
> > Hi Ville
> >
> > The fix is in the next patch.
> >
> > This pach changes the 4096 to page size macro as the BUG on is based on
Hi Ville
The fix is in the next patch.
This pach changes the 4096 to page size macro as the BUG on is based on that
macro explicitly.
Br
Vinod
From: Ville Syrjälä
Sent: Thursday, January 11, 2024 3:44:22 pm
To: Govindapillai, Vinod
Cc: intel-gfx
On Wed, 2023-11-15 at 11:07 +0200, Jouni Högander wrote:
> We are preparing for Xe driver. I915 and Xe object implementation are
> differing. Do not use i915_gem_object->base directly. Instead use
> intel_bo_to_drm_bo.
>
> Signed-off-by: Jouni Högander
> Signed-off-by: Maarten Lankhorst
> ---
On Wed, 2023-11-15 at 11:07 +0200, Jouni Högander wrote:
> Split out code from intel_fbdev that can not be share between i915 and
> xe. Create new i915 specific source/header file intel_fbdev_fb.[ch] which
> contains this code.
>
> Signed-off-by: Jouni Högander
> ---
>
On Thu, 2023-11-16 at 11:05 +0200, Mika Kahola wrote:
> entry_setup_frames variable is defined as u8. However, the
> function call intel_psr_entry_setup_frames() can return
> negative error code. There is a type mismatch here, so let's
> switch to use int here as well.
>
> Fixes: 2b981d57e480
Hi Ville,
On Mon, 2023-11-06 at 22:12 +0200, Ville Syrjälä wrote:
> On Thu, Nov 02, 2023 at 11:55:18PM +0200, Vinod Govindapillai wrote:
> > If both PSR2 + FBC is supported, in cases where the selective
> > fetch area is greater than 25% of the screen area, FBC might
> > be more efficient.
>
>
On Fri, 2023-11-03 at 12:33 +0200, Jani Nikula wrote:
> On Fri, 03 Nov 2023, "Govindapillai, Vinod"
> wrote:
> > Hi,
> >
> >
> > On Fri, 2023-11-03 at 11:21 +0200, Jani Nikula wrote:
> > > On Fri, 03 Nov 2023, Vinod Govindapillai
Hi,
On Fri, 2023-11-03 at 11:21 +0200, Jani Nikula wrote:
> On Fri, 03 Nov 2023, Vinod Govindapillai
> wrote:
> > Implement the alternate WA for the underruns when both PSR2
> > and FBC is enabled.
>
> But we don't enable FBC when PSR2 is enabled, for display 12+.
>
> See intel_fbc.c line
Hi Swati,
Realized that I cannot remove the display runtime info from i915_capabilties
until IGT start using
this new created entry.
So excluded the patch to remove the redundant info from i915_capabilties from
this series
A new version is sent! Sorry for the confusion!
BR
vinod
On Tue,
On Tue, 2023-10-03 at 22:42 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Plane stride is always a multiple of 64 bytes. Remove the
> pointless check that really doesn't have anything to do
> with FBC.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c |
On Tue, 2023-10-03 at 22:42 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Carve up pixel_format_is_valid() into per-platform variants to
> make it easier to see what limits are actually being imposed.
>
> Note that the XRGB1555 can be dropped from the g4x+ variant
> since the plane no
Thanks for clarifications.. This is now
Reviewed-by: Vinod Govindapillai
On Mon, 2023-10-02 at 10:02 +0300, Ville Syrjälä wrote:
> On Sun, Oct 01, 2023 at 10:53:37AM +0000, Govindapillai, Vinod wrote:
> > Hi Ville,
> >
> >
> > On Thu, 2023-09-14 at 14:38
On Thu, 2023-09-14 at 14:38 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Carve up pixel_format_is_valid() into per-platform variants to
> make it easier to see what limits are actually being imposed.
>
> Note that the XRGB1555 can be dropped from the g4x+ variant
> since the plane no
On Thu, 2023-09-14 at 14:38 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Carve up rotation_is_valid() into per-platform variants to
> make it easier to see what limits are actually being imposed.
>
> TODO: maybe go for vfuncs later
>
> Signed-off-by: Ville Syrjälä
> ---
>
Hi Ville,
On Thu, 2023-09-14 at 14:38 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Carve up tiling_is_valid() into per-platform variants to
> make it easier to see what limits are actually being imposed.
>
> TODO: maybe go for vfuncs later
>
> Signed-off-by: Ville Syrjälä
> ---
>
Hi Ville,
On Thu, 2023-09-14 at 14:38 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Carve up stride_is_valid() into per-platform variants to
> make it easier to see what limits are actually being imposed.
>
> TODO: maybe go for vfuncs later
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Thu, 2023-09-28 at 18:55 +0300, Ville Syrjälä wrote:
> On Sat, Sep 23, 2023 at 01:51:15AM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: fbc on any planes (rev3)
> > URL : https://patchwork.freedesktop.org/series/123180/
> > State : failure
> >
> > == Summary ==
> >
> >
On Mon, 2023-09-25 at 15:16 +0300, Jani Nikula wrote:
> On Fri, 22 Sep 2023, Vinod Govindapillai
> wrote:
> > FBC can be supported in first three planes in lnl
>
> When you're cross-posting to intel-xe and intel-gfx lists, you need to
> actually say what you want done with these patches.
On Wed, 2023-09-13 at 13:38 +0300, Ville Syrjälä wrote:
> On Mon, Sep 04, 2023 at 02:55:17PM +0300, Vinod Govindapillai wrote:
> > For LNL onwards, FBC can be supported on planes with per
> > pixel alpha
> >
> > Bspec: 69560
> > Signed-off-by: Vinod Govindapillai
> > ---
> >
Ville Syrjälä
Sent: Wednesday, September 13, 2023 1:38:23 PM
To: Govindapillai, Vinod
Cc: intel...@lists.freedesktop.org ; Roper,
Matthew D ; intel-gfx@lists.freedesktop.org
; Syrjala, Ville
Subject: Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/lnl: FBC is supported with per
pixel alpha
On Mon, S
On Thu, 2023-09-07 at 08:37 -0700, Lucas De Marchi wrote:
> From: Clint Taylor
>
> If a particular pipe is disabled by fuse also remove the FBC for that
> pipe.
>
> Bspec: 69464
> Cc: Anusha Srivatsa
> Cc: Gustavo Sousa
> Signed-off-by: Clint Taylor
> Reviewed-by: Matt Roper
>
On Thu, 2023-09-07 at 08:37 -0700, Lucas De Marchi wrote:
> From: Matt Roper
>
> FBC is no longer limited by pipe: add the defines for pipes B and C that
> will be used by platforms supporting FBC on such pipes.
>
> Bspec: 68881, 68904
> Signed-off-by: Matt Roper
> Signed-off-by: Lucas De
Thanks Ville. Updated the patch as per your comments.
About the WA, I am planning to send that as two separate patches one were we
enabled FBC + PSR2
based on some conditions and the next one this WA
BR
Vinod
On Fri, 2023-09-01 at 16:10 +0300, Ville Syrjälä wrote:
> On Fri, Sep 01, 2023 at
On Mon, 2023-08-28 at 17:16 -0700, Matt Roper wrote:
> On Mon, Aug 28, 2023 at 09:20:34AM +0300, Vinod Govindapillai wrote:
> > In LNL onwards, FBC can be associated to the first three planes.
>
> The title of this patch shouldn't say "any plane" when the reality is
> that only the first three
On Tue, 2023-08-29 at 10:50 +0300, Ville Syrjälä wrote:
> On Mon, Aug 28, 2023 at 09:20:34AM +0300, Vinod Govindapillai wrote:
> > In LNL onwards, FBC can be associated to the first three planes.
> > The FBC will be enabled for first FBC capable visible plane
> > until the userspace can select one
On Mon, 2023-08-28 at 16:58 -0700, Matt Roper wrote:
> On Mon, Aug 28, 2023 at 09:20:32AM +0300, Vinod Govindapillai wrote:
> > FBC restriction with PSR2 can be removed from LNL onwards
> >
> > Signed-off-by: Vinod Govindapillai
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
> >
On Mon, 2023-08-28 at 12:00 +0300, Jani Nikula wrote:
> On Mon, 28 Aug 2023, Vinod Govindapillai
> wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index aefad14ab27a..b207774f3c33 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++
On Tue, 2023-08-22 at 15:57 +0300, Jani Nikula wrote:
> On Fri, 18 Aug 2023, Vinod Govindapillai
> wrote:
> > Modify intel_dp_has_audio to handle DP-MST as well.
> >
> > Signed-off-by: Vinod Govindapillai
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
> > 1 file changed,
Hi Jani
From: Jani Nikula
Sent: Tuesday, August 8, 2023 4:23 PM
To: Govindapillai, Vinod ;
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: optimize DP 2.0 sdp
split update config
On Fri, 04 Aug 2023, Vinod Govindapillai
On Tue, 2023-06-06 at 13:32 +0300, Jani Nikula wrote:
> On Tue, 06 Jun 2023, Vinod Govindapillai
> wrote:
> > SAGV configuration support for MTL
> >
> > v2: added one missing patch in the previous version
> >
> > v3: chekcpatch warning fixes
> > update index handling for the icl/tgl QGV
On Mon, 2023-06-05 at 12:49 +0300, Imre Deak wrote:
> On Thu, Jun 01, 2023 at 07:03:49PM +0300, Vinod Govindapillai wrote:
> > From MTL onwards, we need to find the best QGV point based on
> > the required data rate and pass the peak BW of that point to
> > the punit to lock the corresponding QGV
On Thu, 2023-06-01 at 11:34 -0300, Gustavo Sousa wrote:
> Hi, Vinod.
>
> I have some comments for this version, please see them below. With those
> fixed,
>
> Acked-by: Gustavo Sousa
>
> Quoting Vinod Govindapillai (2023-06-01 09:19:23-03:00)
> > From: Mika Kahola
> >
> > MTL introduces a
on that.
Btw, sorry about the screw up with my previous replay formats - was using
phone!!
BR
Vinod
On Thu, 2023-05-25 at 11:58 -0300, Gustavo Sousa wrote:
> Quoting Govindapillai, Vinod (2023-05-25 11:31:05-03:00)
> > Hi
> >
> > (...)
> >
> > Can only the ph
Hi
I think so far with my trials port clock changes in sync with phys. As pmdemand
atomic check is called many times, I don't think optimizing is bad.
Br
Vinod
From: Sousa, Gustavo
Sent: Thursday, 25 May 2023, 17:58
To: Govindapillai, Vinod ;
intel-gfx
Hi
From: Sousa, Gustavo
Sent: Thursday, 25 May 2023, 17:06
To: Govindapillai, Vinod ;
intel-gfx@lists.freedesktop.org
Cc: Syrjala, Ville ; Lisovskiy, Stanislav
; Kahola, Mika ;
Saarinen, Jani
Subject: Re: [PATCH v8 7/7] drm/i915/mtl: Add support for PM
On Tue, 2023-05-23 at 16:14 +0300, Jani Nikula wrote:
> On Tue, 23 May 2023, "Govindapillai, Vinod"
> wrote:
> > On Tue, 2023-05-23 at 12:01 +0300, Jani Nikula wrote:
> > > On Tue, 23 May 2023, Vinod Govindapillai
> > > wrote:
> > > > From M
On Tue, 2023-05-23 at 12:05 +0300, Jani Nikula wrote:
> On Tue, 23 May 2023, Vinod Govindapillai
> wrote:
> > Extract intel_bw_check_qgv_points() from intel_bw_atomic_check
> > to facilitate future platform variations in handling SAGV
> > configurations.
> >
> > Signed-off-by: Vinod
On Tue, 2023-05-23 at 12:01 +0300, Jani Nikula wrote:
> On Tue, 23 May 2023, Vinod Govindapillai
> wrote:
> > From MTL onwwards, pcode locks the QGV point based on peak BW of
> > the intended QGV point passed by the driver. So the peak BW
> > calculation must match the value expected by the
Hi Gustavo,
Thanks for the comments. Some inline responses are below!
On Fri, 2023-05-12 at 17:43 -0300, Gustavo Sousa wrote:
> Quoting Govindapillai, Vinod (2023-05-11 20:24:55)
> > Hello
> >
> > Thanks for the comments. Pls see some inline replies..
> >
> >
Hello
Thanks for the comments. Pls see some inline replies..
On Thu, 2023-04-27 at 17:24 -0300, Gustavo Sousa wrote:
> Quoting Vinod Govindapillai (2023-04-27 12:00:15)
> > From: Mika Kahola
> >
> > Display14 introduces a new way to instruct the PUnit with
> > power and bandwidth requirements
On Fri, 2023-05-05 at 23:46 +0300, Imre Deak wrote:
> Prevent downgrading the link training maximum lane count/rate if the
> sink is disconnected - and so the link training failure is expected. In
> such cases modeset failures due to the reduced max link params would be
> just confusing for user
On Fri, 2023-05-05 at 23:46 +0300, Imre Deak wrote:
> If a sink is disconnected it's expected that link training actions will
> fail on it, so downgrade the error messages about such actions to be a
> debug message. Such - expected - link training failures are more
> frequent after a follow up
On Sat, 2023-05-06 at 17:42 +0300, Stanislav Lisovskiy wrote:
> By my own mistake, after adding !IS_DG2 into wrong branch,
> bxt_set_cdclk started to execute code intended for platforms
> gen < 11, which is wrong.
> Move IS_DG2 check to better place.
>
> Fixes: ceb0cc3b4288 ("drm/i915:
On Thu, 2023-05-04 at 02:10 +0300, Imre Deak wrote:
> If a sink is disconnected it's expected that link training actions will
> fail on it, so downgrade the error messages about such actions to be a
> debug message. Such - expected - link training failures are more
> frequent after a follow up
Hi Stan
On Tue, 2023-04-25 at 11:13 +0300, Stanislav Lisovskiy wrote:
> Display to communicate display pipe count/CDCLK/voltage configuration
> to Pcode for more accurate power accounting for DG2.
> Existing sequence is only sending the voltage value to the Pcode.
> Adding new sequence with
On Thu, 2023-04-27 at 18:04 +0300, Ville Syrjälä wrote:
> On Thu, Apr 27, 2023 at 06:00:10PM +0300, Vinod Govindapillai wrote:
> > > From MTL onwwards, pcode locks the QGV point based on peak BW of
> > the intended QGV point passed by the driver. So the peak BW
> > calculation must match the value
On Fri, 2023-03-17 at 17:58 -0700, Radhakrishna Sripada wrote:
> Communicating QGV points restriction to PUnit happens via PM Demand
> instead of the Pcode mailbox in the previous platforms. GV point
> restriction is handled by the PM demand code.
>
> Signed-off-by: Radhakrishna Sripada
> ---
On Tue, 2023-04-18 at 12:25 +0300, Lisovskiy, Stanislav wrote:
> On Sun, Apr 16, 2023 at 06:54:15PM +0300, Vinod Govindapillai wrote:
> > From MTL onwwards, pcode locks the QGV point based on peak BW of
> > the intended QGV point passed by the driver. So the peak BW
> > calculation must match the
On Thu, 2023-03-02 at 18:10 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hardcoded masks with just a loop over all hpd
> pins using the _hotplug_mask() functions.
>
> Signed-off-by: Ville Syrjälä
> ---
Reviewed-by: Vinod Govindapillai
> drivers/gpu/drm/i915/i915_irq.c
On Fri, 2023-03-03 at 18:58 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pair each _hotplug_enables() function with
> a corresponding _hotplug_mask() function so that
> we can determine right bits to clear on a per hpd_pin basis.
> We'll need this for turning on HPD sense for a specific
On Fri, 2023-04-14 at 17:21 +0300, Ville Syrjälä wrote:
> On Fri, Apr 14, 2023 at 01:23:16PM +0000, Govindapillai, Vinod wrote:
> > Hi Ville
> >
> > Btw, I dont see the _hotplug_mask() defined anywhere..
> > Am I missing any patch?
>
> The previous patch in the
Hi Ville
Btw, I dont see the _hotplug_mask() defined anywhere..
Am I missing any patch?
BR
Vinod
On Fri, 2023-04-14 at 15:59 +0300, Govindapillai, Vinod wrote:
> On Thu, 2023-03-02 at 18:10 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a mechanism b
On Thu, 2023-03-02 at 18:10 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We need to untangle the mess where some SKL machines (at least)
> declare both DDI A and DDI E to be present in their VBT, and
> both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
> real DP->VGA
On Thu, 2023-03-02 at 18:10 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a mechanism by which we can enable the HPD sense for
> individual encoders.
>
> This will be used during eDP probing to figure out if
> anything is actually connected. The normal intel_hpd_irq_setup()
> thing
On Wed, 2023-04-05 at 13:41 +0300, Jani Nikula wrote:
> Fix the warning:
>
> drivers/gpu/drm/i915/intel_wakeref.h:118: warning: expecting prototype
> for intel_wakeref_get_if_in_use(). Prototype was for
> intel_wakeref_get_if_active() instead
>
> Signed-off-by: Jani Nikula
> ---
Thanks
On Wed, 2023-04-05 at 13:41 +0300, Jani Nikula wrote:
> There's not much point in a static work function having a kernel-doc
> comment. Just clean it up and make it a regular comment.
>
> This fixes the kernel-doc warnings:
>
> drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Function
>
Hi Stan,
On Fri, 2023-03-24 at 15:51 +0200, Stanislav Lisovskiy wrote:
> According to spec, we should check if output_bpp * pixel_rate is less
> than DDI clock * 72, if UHBR is used.
>
> v2: - s/pipe_config/crtc_state/ (Jani Nikula)
> - Merged previous patch into that one, to remove empty
Hi Mika
There were some comments from the previous version
https://patchwork.freedesktop.org/patch/517048/#comment_943150
I think you should address them?
BR
vinod
On Mon, 2023-03-27 at 15:34 +0300, Mika Kahola wrote:
> From: Radhakrishna Sripada
>
> XELPDP has C10 and C20 phys from
On Mon, 2023-03-27 at 15:34 +0300, Mika Kahola wrote:
> Create a separate file to store registers for PICA chips
> C10 and C20.
>
> v2: Rename file (Jani)
> v3: Use _PICK_EVEN_2RANGES() macro (Lucas)
> Coding style fixed (Lucas)
>
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika
On Mon, 2023-03-27 at 15:34 +0300, Mika Kahola wrote:
> Add DP rates for Meteorlake.
>
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
Reviewed-by: Vinod Govindapillai
> drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
> 1 file changed, 14
On Mon, 2023-03-27 at 15:34 +0300, Mika Kahola wrote:
> From: Clint Taylor
>
> Initialization sequences and C10 phy are in place to be able to enable
> the first 2 ports of MTL. The other ports use C20 phy that still need
> to be properly added. Enable the first ports for now, keeping a TODO
>
On Mon, 2023-03-27 at 09:42 +0300, Stanislav Lisovskiy wrote:
> For obvious reasons, we use compressed bpp instead of pipe bpp for
> DSC DP SST case. Lets be consistent and use compressed bpp instead of
> pipe bpp, also in DP MST DSC case.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
>
On Wed, 2023-03-22 at 16:36 +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2023 at 04:20:50PM +0200, Vinod Govindapillai wrote:
> > Wrong offsets are calculated to read QGV point registers. Fix it
> > to read from the correct registers.
> >
> > v2: Avoid magic number and better handling the second
Hi stan
combining two threads..
On Tue, Mar 14, 2023 at 11:50:20AM +0200, Govindapillai, Vinod wrote:
> > Hi Stan
> >
> > Few other places also do not ceil the result as per the 64631
> >
> > deinterleave, peakbw, clperchgroup
> >
> > Well! I am not
Hi Stan
Few other places also do not ceil the result as per the 64631
deinterleave, peakbw, clperchgroup
Well! I am not sure if this has any real impact, but FYI
Vinod
On Tue, 2023-03-14 at 11:27 +0200, Govindapillai, Vinod wrote:
> Hi Stan,
>
>
>
> On Fri, 2023-03-10
Hi Stan,
On Fri, 2023-03-10 at 16:40 +0200, Stanislav Lisovskiy wrote:
> Currently in our bandwidth calculations for QGV
> points we round up the calculations.
> Recently there was an update to BSpec, recommending
> to floor those calculations.
> The reasoning behind this was that,
Hi Stan
On Mon, 2023-03-06 at 10:04 +0200, Stanislav Lisovskiy wrote:
> We have currently the issue with some BPPs when using DSC.
> According the HW team the reason is that single VDSC engine instance,
> has some BW limitations which have to be accounted, so whenever
> we approach around 90% of
Hi
Reviewed-by: Vinod Govindapillai
BR
vinod
PS: With this patch seems my comment for the prev patch in this series might
not be relevant.
On Wed, 2023-01-25 at 20:52 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> FBC on gen2/3 seems to trigger page table errors. No visual
>
Hi,
On Wed, 2023-01-25 at 20:52 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull the EMR calculation into small helpers.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 46 ++---
> 1 file changed, 25 insertions(+), 21
Hi
Reviewed-by: Vinod Govindapillai
BR
Vinod
On Wed, 2023-01-25 at 20:52 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> PGTBL_ER contains the individual reasons for the page table
> error interrupt. Dump it out.
>
> Signed-off-by: Ville Syrjälä
> ---
>
Hello
Reviewed-by: Vinod Govindapillai
BR
Vinod
On Wed, 2023-01-25 at 20:52 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The gen2/gen3 irq code is supposed to be identical apart
> from the 32bit vs. 16bit access width. The recent change
> to intel_de_rmw() ruined that symmetry.
Thanks
Reviewed-by: Vinod Govindapillai
BR
Vinod
On Wed, 2023-01-25 at 20:52 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> At least on some platforms (tested on ctg) the way
> vgacon does screen blanking seems to flag constant
> FIFO underruns, which means we have to be prepared
>
Hi Jouni,
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
On Wed, 2023-01-25 at 12:44 +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_*
Thanks Jani. I updated the patch. Could you please push to the drm-tip.
Thanks
Vinod
On Mon, 2022-11-21 at 15:15 +0200, Jani Nikula wrote:
> On Tue, 01 Nov 2022, Vinod Govindapillai
> wrote:
> > Enable the SDP split configuration for DP2.0.
> >
> > v2: Move the register handling out of
Sorry.. please ignore this! I accidentally resent this!
This was already reviewed by
On Tue, 2022-10-11 at 12:25 +0300, Vinod Govindapillai wrote:
> As some faulty displays generate long HPDs even while connected to ports
> can cause CI execution issues. Add a provision to ignore such long HPDs
On Mon, 2022-10-10 at 14:08 +0200, Andrzej Hajda wrote:
> On 10.10.2022 10:34, Vinod Govindapillai wrote:
> > Some panels generate long HPD events even while connected to
> > the port. This cause some unexpected CI execution issues. A
> > new flag is added to track if such spurious long HPDs can
When tried locally, dim sparse were ok!
---
Sparse version: 0.6.4 (Ubuntu: 0.6.4-2)
Commit: drm/i915/display: ignore long HPDs based on a flag
Okay!
Commit: drm/i915/display: debugfs entry to control ignore long hpd flag
Okay!
---
BR
vinod
On Mon, 2022-10-10 at 08:52 +, Patchwork
On Thu, 2022-09-01 at 13:11 +0300, Stanislav Lisovskiy wrote:
> Whenever we are not able to get enough timeslots
> for required PBN, let's try to allocate those
> using DSC, just same way as we do for SST.
>
> v2: Removed intel_dp_mst_dsc_compute_config and refactored
>
Reviewed-by: Vinod Govindapillai
Vinod
On Thu, 2022-09-01 at 13:11 +0300, Stanislav Lisovskiy wrote:
> We would be using almost same code to loop through bpps while calling
> drm_dp_atomic_find_vcpi_slots - lets remove this duplication by
> introducing a new
Hi Stan,
I wonder if it is better if you reorder the 3 and 4 patches in this - move this
4/4 before the 3rd
one and modify the 3rd one accordingly.
Also, instead of getting rid of limits, keep limits and populate the limits
according to dsc or
normal dp_mst. What do you think?
BR
vinod
On
Reviewed-by: Vinod Govindapillai
On Mon, 2022-08-29 at 12:58 +0300, Stanislav Lisovskiy wrote:
> We currently always exit that bpp loop because drm_dp_atomic_find_vcpi_slots
> doesn't care if we actually can fit those or not.
> I think that wasn't the initial intention here, especially when
>
1 - 100 of 119 matches
Mail list logo
