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
>
Reviewed-by: Vinod Govindapillai
On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> Adding DP DSC register definitions, we might need for further
> DSC implementation, supporting MST and DP branch pass-through mode.
>
> v2: - Fixed checkpatch comment warning
> v3: - Removed
On Thu, 2022-08-25 at 18:17 +0300, Lisovskiy, Stanislav wrote:
> On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> > Hi Stan,
> >
> > Some comments inline..
> >
> > On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > &
Hi Stan,
Some comments inline..
On Mon, 2022-08-22 at 12:40 +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
Hi Stan,
Please find my comments inline
On Mon, 2022-04-11 at 19:25 +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
On Fri, 2022-05-20 at 00:35 +0200, Andrzej Hajda wrote:
> Handling HPD during driver removal is pointless, and can cause different
> use-after-free/concurrency issues:
> 1. Setup of deferred fbdev after fbdev unregistration.
> 2. Access to DP-AUX after DP-AUX removal.
Thanks.
Reviewed-by: Vinod
Hi Stan
Pls see some comments inline..
BR
Vinod
On Wed, 2022-05-18 at 13:59 +0300, Stanislav Lisovskiy wrote:
> Otherwise we seem to get FIFO underruns. It is being disabled
> anyway, so kind of logical to write those as zeroes, even if
> disabling is temporary.
>
> Signed-off-by: Stanislav
On Thu, 2022-04-14 at 20:59 +0300, Ville Syrjälä wrote:
> On Wed, Apr 06, 2022 at 08:43:11PM +0300, Vinod Govindapillai wrote:
> > In configurations with single DRAM channel, for usecases like
> > 4K 60 Hz, FIFO underruns are observed quite frequently. Looks
> > like the wm0 watermark values need
Thanks!
Reviewed-by: Vinod Govindapillai
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: 11 April 2022 11:14
> To: intel-gfx@lists.freedesktop.org
> Cc: Lisovskiy, Stanislav ; Govindapillai, Vinod
> ; Saarinen, Jani
> Subject: [PATCH 2/2] drm/i915
On Fri, 2022-04-08 at 15:52 +0300, Stanislav Lisovskiy wrote:
> If ret isn't zero, it is almost for sure ETIMEDOUT, because
> we use it in wait_for macro which does continuous retries
> until timeout is reached. If we still ran out of time and
> retries, we most likely would be interested in
On Thu, 2022-04-07 at 09:43 +0300, Lisovskiy, Stanislav wrote:
> On Wed, Apr 06, 2022 at 09:09:06PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 06, 2022 at 08:14:58PM +0300, Lisovskiy, Stanislav wrote:
> > > On Wed, Apr 06, 2022 at 05:01:39PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Apr 06,
On Wed, 2022-04-06 at 17:01 +0300, Ville Syrjälä wrote:
> On Wed, Apr 06, 2022 at 04:45:26PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, Apr 06, 2022 at 03:48:02PM +0300, Ville Syrjälä wrote:
> > > On Mon, Apr 04, 2022 at 04:49:18PM +0300, Vinod Govindapillai wrote:
> > > > In configurations
On Wed, 2022-04-06 at 12:58 +0300, Lisovskiy, Stanislav wrote:
> On Wed, Apr 06, 2022 at 12:19:19PM +0300, Govindapillai, Vinod wrote:
> > Hi,
> >
> > On Wed, 2022-04-06 at 10:48 +0300, Lisovskiy, Stanislav wrote:
> > > On Wed, Apr 06, 2022 at 12:51:29AM +03
On Wed, 2022-04-06 at 11:14 +0300, Lisovskiy, Stanislav wrote:
> On Mon, Apr 04, 2022 at 04:49:18PM +0300, Vinod Govindapillai wrote:
> > In configurations with single DRAM channel, for usecases like
> > 4K 60 Hz, FIFO underruns are observed quite frequently. Looks
> > like the wm0 watermark
Hi,
On Wed, 2022-04-06 at 10:48 +0300, Lisovskiy, Stanislav wrote:
> On Wed, Apr 06, 2022 at 12:51:29AM +0300, Govindapillai, Vinod wrote:
> > Hi Stan
> >
> > Nice Find! Couple of clarifications, please check inline...
> >
> > On Tue, 2022-04-05 at 13:41
Hi Stan
Nice Find! Couple of clarifications, please check inline...
On Tue, 2022-04-05 at 13:41 +0300, Stanislav Lisovskiy wrote:
> Currently skl_pcode_try_request function doesn't
> properly handle return value it gets from
> snb_pcode_rw, but treats status != 0 as success,
> returning true,
On Thu, 2022-03-24 at 08:39 +, Murthy, Arun R wrote:
> > }
> >
> > +static unsigned int dg2_max_bw(struct drm_i915_private *i915) {
> > + struct intel_bw_info *bi = >max_bw[0];
> > +
> > + return bi->deratedbw[0];
> > +}
>
> Would it look better to have this as a macro rather than a
On Tue, 2022-03-08 at 19:32 +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't
On Tue, 2022-03-08 at 19:32 +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,
> log it,
On Tue, 2022-03-08 at 19:32 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> GLK doesn't support SAGV, so with CNL gone there is no
> use for having a DISPLAY_VER==10 SAGV block time in the code.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Vinod Govindapillai
> ---
>
101 - 121 of 121 matches
Mail list logo
