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 c
On Thu, Oct 21, 2021 at 07:56:23PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> TileF(Tile4 in bspec) format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Fixed wrong case condition(Jani Nikula)
On Mon, Oct 18, 2021 at 02:50:22PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Async flips are only capable of changing PLANE_SURF, hence we
> they can't easily be used with planar formats.
>
> Older platforms could require updating AUX_DIST as well, which
> is not possible. We'd have
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 t
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 c
On Wed, Oct 27, 2021 at 07:56:25PM +0300, Imre Deak wrote:
> On Wed, Oct 27, 2021 at 06:46:53PM +0300, Stanislav Lisovskiy wrote:
> > TileF(Tile4 in bspec) format is 4K tile organized into
> > 64B subtiles with same basic shape as for legacy TileY
> > which will be supported by Display13.
>
> Is i
On Thu, Oct 28, 2021 at 02:03:49AM +0530, Ramalingam C wrote:
> On 2021-10-27 at 18:46:53 +0300, Stanislav Lisovskiy wrote:
> > TileF(Tile4 in bspec) format is 4K tile organized into
> > 64B subtiles with same basic shape as for legacy TileY
> > which will be supported by Display13.
> >
> > v2: -
On Thu, Oct 28, 2021 at 02:53:34AM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> TileF(Tile4 in bspec) format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Fixed wrong case condition(Jani Nikula)
On Thu, Oct 28, 2021 at 10:39:42AM +0300, Imre Deak wrote:
> On Thu, Oct 28, 2021 at 09:58:52AM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, Oct 27, 2021 at 07:56:25PM +0300, Imre Deak wrote:
> > > On Wed, Oct 27, 2021 at 06:46:53PM +0300, Stanislav Lisovskiy wrote:
> >
On Thu, Oct 28, 2021 at 10:53:25AM +0300, Imre Deak wrote:
> On Thu, Oct 28, 2021 at 10:49:34AM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Oct 28, 2021 at 10:39:42AM +0300, Imre Deak wrote:
> > > On Thu, Oct 28, 2021 at 09:58:52AM +0300, Lisovskiy, Stanislav wrote:
> >
On Thu, Oct 28, 2021 at 04:03:32PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 27, 2021 at 08:11:37PM +0300, Lisovskiy, Stanislav wrote:
> > On Mon, Oct 18, 2021 at 02:50:26PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Chop skl_progra
On Thu, Oct 28, 2021 at 04:59:28PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 28, 2021 at 04:54:19PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Oct 28, 2021 at 04:03:32PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 27, 2021 at 08:11:37PM +0300, Lisovskiy, Stanislav wrote:
&
On Fri, Oct 29, 2021 at 10:18:02PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Looks like our VBIOS/GOP generally fail to turn the DP dual mode adater
> TMDS output buffers back on after a reboot. This leads to a black screen
> after reboot if we turned the TMDS output buffers off prior
On Fri, Oct 29, 2021 at 10:18:01PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We will need to do some i2c poking from the encoder->shutdown() hook.
> Currently that gets called after irqs have been turned off. We still
> poll the gmbus status bits even if the interrupt never arrives so
On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> Each VDSC operates with 1ppc throughput, hence enable the second
> VDSC engine when moderate is higher that the current cdclk.
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > > To: Kulkarni, Vandita
> > > Cc: intel-gfx@lists.fre
On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> wrote:
> > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> >> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita wrote:
On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > wrote:
> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
On Fri, May 14, 2021 at 03:57:38PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_plane_atomic_calc_changes() deals with both the old and
> new crtc/plane states. Make the variable names reflect that
> more clearly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
On Fri, May 14, 2021 at 03:57:39PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The intention was to check whether the primary plane is enabled
> without any sprites planes being enabled. Instead we ended up checking
> whether just any one of the planes is enabled. g4x isn't vlv/chv and
On Fri, May 14, 2021 at 03:57:40PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Be consistent in that active_planes bitmask fits in a u8.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> 1 file changed, 3 insert
On Fri, Sep 17, 2021 at 03:32:51PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 16, 2021 at 07:24:21PM +0300, Lisovskiy, Stanislav wrote:
> > On Fri, May 14, 2021 at 03:57:39PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The intention was t
On Fri, May 14, 2021 at 03:57:41PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The w/a database lists this for both ctg and elk. So let's apply it to
> elk as well. And add the w/a name.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 12
> 1 f
On Fri, May 14, 2021 at 03:57:42PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If HPLL watermarks are already enabled, let's not mark them as
> disabled by forgetting to bump 'level' before we call
> g4x_raw_plane_wm_set().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i91
On Thu, Sep 23, 2021 at 01:28:21PM +0300, Jani Nikula wrote:
> On Thu, 23 Sep 2021, Stanislav Lisovskiy
> wrote:
> > @@ -1941,6 +1951,10 @@ static bool gen12_plane_format_mod_supported(struct
> > drm_plane *_plane,
> > if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> >
On Thu, Sep 23, 2021 at 01:44:11PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Sep 23, 2021 at 01:28:21PM +0300, Jani Nikula wrote:
> > On Thu, 23 Sep 2021, Stanislav Lisovskiy
> > wrote:
> > > @@ -1941,6 +1951,10 @@ static bool
> > > gen12_plane_format_mod_s
On Wed, Sep 22, 2021 at 05:05:12PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 17, 2021 at 06:34:22PM +0300, Lisovskiy, Stanislav wrote:
> > On Fri, May 14, 2021 at 03:57:42PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > If HPLL watermarks
On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote:
> > TileF(Tile4 in bspec) format is 4K tile organized into
> > 64B subtiles with same basic shape as for legacy TileY
> > which will be supported by Display13.
>
>
On Fri, May 14, 2021 at 03:57:43PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Split g4x_compute_pipe_wm() into two halves. The first half computes
> the new raw watermarks, and the second half munges those up into real
> watermarks for the particular pipe.
>
> We can reuse the second
On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote:
> On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote:
> > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 23, 2021 at 11:48:58A
On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote:
> > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote:
> > > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote:
> >
On Tue, Sep 28, 2021 at 11:47:51PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 28, 2021 at 11:36:51PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote:
&
On Mon, Jul 26, 2021 at 11:00:46PM -0700, Matt Roper wrote:
> ADL_P requires that we disable underrun recovery when downscaling (or
> using the scaler for YUV420 pipe output), using DSC, or using PSR2.
> Otherwise we should be able to enable the underrun recovery.
>
> On DG2 we need to keep underr
On Thu, May 06, 2021 at 10:38:36AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When scanning out NV12 if we at any time have the plane enabled
> while the scaler is disabled we get a pretty catastrophics
> underrun.
>
> Let's reorder the operations so that we try to avoid that happenin
On Fri, May 07, 2021 at 07:28:01PM -0700, Matt Roper wrote:
> From: Vandita Kulkarni
>
> Update MBUS_CTL register if the 2 mbus can be joined as per the current
> DDB allocation and active pipes, also update hashing mode and pipe
> select bits as per the sequence mentioned in the bspec.
Reviewe
On Fri, May 14, 2021 at 08:10:24PM -0700, Matt Roper wrote:
> From: Ville Syrjälä
>
> The dbuf slices are going to be split across several MBUS units.
> The actual dbuf programming will use offsets relative to the
> MBUS unit. To accommodate that we shall store the MBUS relative
> offsets into th
On Fri, May 14, 2021 at 08:10:18PM -0700, Matt Roper wrote:
> XE_LPD reduces the number of regular watermark latency levels from 8
> to 6 on non-dgfx platforms. However the hardware also adds a special
> purpose SAGV wateramrk (and an accompanying transition watermark) that
> will be used by the h
On Fri, May 14, 2021 at 08:10:13PM -0700, Matt Roper wrote:
> XE_LPD brings enhanced underrun recovery: the hardware can somewhat
> mitigate underruns by using an interpolated replacement pixel (soft
> underrun) or the previous pixel (hard underrun). Furthermore, underruns
> can now be caused dow
On Fri, May 14, 2021 at 08:10:22PM -0700, Matt Roper wrote:
> From: José Roberto de Souza
>
> Alderlake-P don't have programing sequences for MBUS or DBUF during
> display initializaiton, instead it requires programing to those
> registers during modeset because it to depend on the pipes left
> e
On Fri, May 14, 2021 at 08:10:23PM -0700, Matt Roper wrote:
> From: Vandita Kulkarni
>
> On adlp the two mbuses have two display pipes and
> two DBUFS, Pipe A and D on Mbus1 and Pipe B and C on
> Mbus2. The Mbus can be joined and all the DBUFS can be
> used on Pipe A or B.
Reviewed-by: Stanislav
On Thu, Mar 25, 2021 at 02:44:14AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Accidentally transposed the arguments to skl_plane_wm_level()
> which is causing us to mistakenly think that the plane watermarks
> have/have not changed when the opposite may be true. Swap the
> arguments so
On Thu, Mar 25, 2021 at 02:44:15AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The dbuf bandwidth calculations don't need the planes to be
> added to the state. Each plane's data rate has already been
> precalculated and stored in the crtc state, and that with
> the dbuf slice usage for
On Thu, Mar 25, 2021 at 01:37:31PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 25, 2021 at 11:35:53AM +0200, Lisovskiy, Stanislav wrote:
> > On Thu, Mar 25, 2021 at 02:44:15AM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The dbuf bandwidth c
On Sat, Mar 27, 2021 at 02:59:45AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Don't zero out the watermarks for the Y plane since we've already
> computed them when computing the UV plane's watermarks (since the
> UV plane always appears before ethe Y plane when iterating through
> the
(latency == 0)
> + return;
> +
> /* Display WA #1141: kbl,cfl */
> if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) &&
Reviewed-by: Stanislav Lisovskiy
--
Best Regards,
Lisovskiy S
> intel_crtc_state *cstate,
> }
> }
>
> - /* The number of lines are ignored for the level 0
> watermark. */
> - if (level > 0 && res_lines > 31)
> + if (!skl_wm_has_lines(dev_priv, level))
> +
wp->dbuf_block_size = 512;
Interesting how this small misunderstanding could affect our bugs
previously.
Reviewed-by: Stanislav Lisovskiy
--
Best Regards,
Lisovskiy Stanislav
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 2019-04-11 at 17:36 +0300, Gwan-gyeong Mun wrote:
> The hotplug detection routine of drm_helper_hpd_irq_event() can
> detect
> changing of status of connector, but it can not detect changing of
> edid.
>
> Following scenario requires detection of changing of edid.
>
> 1) plug display dev
>
> + /*
> + * On Geminilake once the CDCLK gets as low as 79200
> + * picture gets unstable, despite that values are
> + * correct for DSI PLL and DE PLL.
> + */
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> + IS_GEMINILAKE(dev_priv))
> +
On Tue, 2019-04-30 at 10:43 +0300, Jani Nikula wrote:
> On Tue, 30 Apr 2019, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > Currently due to regression CI machine
> > displays show corrupt picture.
> > Problem is when CDCLK is as low as 79200, picture gets
> > unstable, while DSI
my concern is
that can this cause some regression for other connector types?
That's why I was checking, that this is a DP connector, so that this
doesn't touch other connector types at least.
> >
> > if (drm_lease_held(file_priv, connector->base.id))
>
confirming that theory).
This could be also fixed in userspace by checking connectors more
carefully - that fix I've also implemented for Intel DDX and attached
to the bug, however seems that this happens also for Wayland.
>
> For entertainment and other reasons, testing the belo
On Thu, 2018-11-29 at 07:37 +, Lisovskiy, Stanislav wrote:
> On Wed, 2018-11-28 at 22:21 +0100, Daniel Vetter wrote:
> >
> > > I tried to read the bug and I have no idea what's going on here.
> > > Userspace
> > > is supposed to shut off outputs that
i915/intel_dp_mst.c
> > > @@ -499,6 +499,8 @@ static void
> > > intel_dp_register_mst_connector(struct drm_connector *connector)
> > > drm_fb_helper_add_one_connector(&dev_priv->fbdev-
> > > > helper,
> > >
> > >
lso because I'm still using old BIOS, which I've got initially
from Vandita?
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Chauhan, Madhav
Sent: Tuesday, December 04, 2018
Hi Jani,
I've tried previously with branch icl-dsi-2018-12-03 for your github repo.
I think it has everything except this 4.12.2018 "fix transcoder state readout"
commit.
I will apply it and try with that now, thanks.
Best Regards,
Lisovskiy Stanislav
Organization: Intel F
.org/show_bug.cgi?id=103184),
and sometimes half of the tests fail with the crc mismatch, I think this is
kind of different thing.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Intel
Ok, I didn't file a bug yet, because I still have suspicion that this could be
a bios thing.
Vandita, Madhav, did you happen to see same issue?
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160
und 1)
[ 13.476994] [drm:pipe_config_err [i915]] *ERROR* mismatch in
scaler_state.scaler_id (expected 0, found -1)
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Chauhan, Madhav
On Mon, 2019-08-19 at 09:05 +, Lisovskiy, Stanislav wrote:
> On Mon, 2019-08-19 at 08:35 +0100, Peres, Martin wrote:
> > On 19/08/2019 10:23, Lisovskiy, Stanislav wrote:
> > > On Wed, 2019-08-07 at 23:07 +0200, Daniel Vetter wrote:
> > > >
> > > >
On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
>
> > > In fact I was wrong - when it worked, it was using exactly those
> > > patches :). With clean drm-tip - it seems to work ocassionally
> > > and it
> > > doesn't update the actual display edid and other stuff, so even
> > > when
> > >
On Tue, 2019-09-03 at 11:49 +, Lisovskiy, Stanislav wrote:
> On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
> >
> > > > In fact I was wrong - when it worked, it was using exactly
> > > > those
> > > > patches :). With clean drm-tip -
On Tue, 2019-09-03 at 17:49 +0200, Daniel Vetter wrote:
> On Tue, Sep 03, 2019 at 11:49:23AM +0000, Lisovskiy, Stanislav wrote:
> > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
> > >
> > > > > In fact I was wrong - when it worked, it was using exactly
On Wed, 2019-09-04 at 11:23 +0200, Daniel Vetter wrote:
>
> > Sure this will work, but still we need somehow to be able to
> > determine
> > this "if it's different" state. In your solution we just move that
> > comparison to drm_connector_update_edid_property, which is quite
> > fine
> > for me.
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow drivers to call drm_atomic_helper_check_modeset() without
> having the crtc helper funcs specified. i915 doesn't need those
> anymore.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_hel
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> i915 doesn't use the crtc_state->plane_changed flag for anything,
> so setting it is pointless.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 7 ---
> 1 file changed,
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We need to insert stuff between the plane and crtc .atomic_check()
> drm_atomic_helper_check_planes() doesn't allow us to do that so
> stop using it and hand roll the loops instead.
>
> Signed-off-by: Ville Syrjälä
On Thu, 2019-09-05 at 13:01 +0200, Maarten Lankhorst wrote:
> Op 05-09-2019 om 12:37 schreef Stanislav Lisovskiy:
> > This counter will be used by drm_helper_probe_detect caller to
> > determine
> > if something else had changed except connection status,
> > like for example edid. Hardware specific
On Fri, 2019-09-06 at 14:23 +0300, Lionel Landwerlin wrote:
> On 06/09/2019 14:14, Stanislav Lisovskiy wrote:
> > In certain situations encoder might be not present for connector,
> > however might be useful to displat probed modes for the connector,
>
> s/displat/display/
Thanks! :)
- Stanislav
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow drivers to call drm_atomic_helper_check_modeset() without
> having the crtc helper funcs specified. i915 doesn't need those
> anymore.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_hel
{
> struct intel_dp *intel_dp = enc_to_intel_dp(&connector-
> >encoder->base);
> struct intel_panel *panel = &connector->panel;
>
> - if (intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> - panel->backlight.max = 0x;
> - el
On Fri, 2019-09-20 at 16:19 +0300, Ville Syrjälä wrote:
> On Fri, Sep 20, 2019 at 01:44:13PM +0300, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, we should try to
> > restrict qgv points, which can't provide
> > enough bandwidth for desired display configuration.
> >
> > Currently we ar
at case as I
understand, is it expected to work this way?
Also, if it is always either one or another, then we probably don't
need "else if" here.
Best Regards,
Lisovskiy Stanislav
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 2019-06-27 at 13:29 +0200, Daniel Vetter wrote:
> On Thu, Jun 27, 2019 at 10:00:14AM +0300, Stanislav Lisovskiy wrote:
> > This series introduce to drm a way to determine if something else
> > except connection_status had changed during probing, which
> > can be used by other drivers as wel
On Fri, 2019-06-28 at 09:54 +0530, Ramalingam C wrote:
> On 2019-06-28 at 11:24:54 +0300, Stanislav Lisovskiy wrote:
> > Added edid checking to dp and hdmi edid setting functions, which
> > are called from detect hooks. The result currently is propagated
> > to calling layer using drm_connector->ch
On Tue, Jun 14, 2022 at 03:55:04PM +0300, Hogander, Jouni wrote:
> On Tue, 2022-06-14 at 15:22 +0300, Stanislav Lisovskiy wrote:
> > We seem to enable PSR2 and selective fetch even if there are no
> > active
> > planes. That seems to causes FIFO underruns at least for ADLP.
> > Those are gone if we
On Tue, Jun 14, 2022 at 03:55:04PM +0300, Hogander, Jouni wrote:
> On Tue, 2022-06-14 at 15:22 +0300, Stanislav Lisovskiy wrote:
> > We seem to enable PSR2 and selective fetch even if there are no
> > active
> > planes. That seems to causes FIFO underruns at least for ADLP.
> > Those are gone if we
On Mon, Jul 11, 2022 at 09:16:01AM +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.
>
> Fix this by checking if old and new crtc encoder masks are differing.
> PSR is
On Mon, Jul 11, 2022 at 02:17:50PM +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.
>
> Fix this by checking if encoder exists in new crtc state and disable
> PSR if
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/dis
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/dis
On Tue, Jan 11, 2022 at 06:45:31PM +0200, Jani Nikula wrote:
> On Tue, 11 Jan 2022, Stanislav Lisovskiy
> wrote:
> > Currently we only recalculate CDCLK if active plane mask changes
> > or if we do a full modeset, however according to BSpec
> > required Dbuf bandwidth calculations also depend on
On Wed, Jan 12, 2022 at 03:50:05PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 11, 2022 at 06:08:12PM +0200, Stanislav Lisovskiy wrote:
> > Currently we only recalculate CDCLK if active plane mask changes
> > or if we do a full modeset, however according to BSpec
> > required Dbuf bandwidth calculati
On Wed, Jan 12, 2022 at 04:50:01PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 12, 2022 at 04:39:17PM +0200, Lisovskiy, Stanislav wrote:
> > On Wed, Jan 12, 2022 at 03:50:05PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 11, 2022 at 06:08:12PM +0200, Stanislav Lisovskiy wrote:
&g
On Tue, Jan 18, 2022 at 01:45:10PM +, Matthew Auld wrote:
> On Fri, 14 Jan 2022 at 08:25, Stanislav Lisovskiy
> wrote:
> >
> > Using i915_gem_object_pin_map_unlocked instead of
> > i915_gem_object_lmem_io_map, would eliminate the need
> > of using I915_BO_ALLOC_CONTIGUOUS, when calling
> > i91
On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Don't just mask off all the PSF GV points when SAGV gets disabled.
> This should in fact cause the Pcode to reject the request since
> at least one PSF point must remain enabled at all times.
Good point, how
On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For modern platforms the spec explicitly states that a
> SAGV block time of zero means that SAGV is not supported.
> Let's extend that to all platforms. Supposedly there should
> be no systems where this isn'
On Wed, Mar 09, 2022 at 09:08:12PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote:
> > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Don't just mask
On Thu, Mar 03, 2022 at 09:12:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We should round up when doing bandwidth calculations to make sure
> our estimates don't fall short of the actual number.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers
On Thu, Mar 03, 2022 at 09:12:05PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current code also forgets to call intel_atomic_lock_global_state()
> when other stuff besides the final min_cdlck changes in the state.
> That means we may throw away data which actually has changed, and
On Thu, Mar 03, 2022 at 09:12:06PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make the dbuf bandwidth min cdclk calculations match the spec
> more closely. Supposedly the arbiter can only guarantee an equal
> share of the total bandwidth of the slice to each active plane
> on that slic
On Thu, Mar 10, 2022 at 10:59:16AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 10, 2022 at 10:22:56AM +0200, Lisovskiy, Stanislav wrote:
> > On Thu, Mar 03, 2022 at 09:12:06PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Make the dbuf bandwi
On Thu, Mar 03, 2022 at 09:12:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make sure the CDCLK is high enough to support the so called
> "maximum pipe read bandwidth" limitation. Specified as
> 51.2 x CDCLK.
Reviewed-by: Stanislav Lisovskiy
>
> Signed-off-by: Ville Syrjälä
> --
On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For modern platforms the spec explicitly states that a
> SAGV block time of zero means that SAGV is not supported.
> Let's extend that to all platforms. Supposedly there should
> be no systems where this isn'
On Wed, Mar 09, 2022 at 06:49:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I'd like to see the SAGV block time we got from the mailbox
> in the logs regardless of whether other factors prevent the
> use of SAGV.
>
> So let's adjust the code to always query the SAGV block time,
> lo
On Wed, Mar 09, 2022 at 06:49:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use separate bitmasks for QGV vs. PSF GV points during
> the computation. Makes the whole thing a lot less confusing.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gp
On Wed, Mar 09, 2022 at 06:49:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Give the pre-icl SAGV control functions a skl_ prefix instead
> of the intel_ prefix to make it a bit more clear that they
> are not some kind of universal things that can be called on
> any platform. Also ma
On Wed, Mar 09, 2022 at 06:49:43PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of leaving the SAGV enable/disable to the first commit
> let's try to disable it first thing to see if we can do it or
> not (disabling SAGV is a safe thing to at any time). This avoids
> running the
On Wed, Mar 09, 2022 at 06:49:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Name all the ICL_PCODE_SAGV_DE_MEM_SS_CONFIG request/response
> bits in a manner that we can actually understand what they're
> doing.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
>
On Wed, Mar 09, 2022 at 06:49:44PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the mailbox returns an exceesively large SAGV block time let's just
> reject it. This avoids having to worry about overflows when we add the
> SAGV block time to the wm0 latency.
>
> We shall put the limi
1 - 100 of 741 matches
Mail list logo
