[Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches

Souza, Jose jose.souza at intel.com
Fri Feb 19 19:35:35 UTC 2021


On Thu, 2021-02-18 at 20:21 +0200, Ville Syrjälä wrote:
> On Thu, Feb 18, 2021 at 05:25:54PM +0000, Souza, Jose wrote:
> > On Thu, 2021-02-18 at 00:14 +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 17, 2021 at 05:24:03PM +0000, Souza, Jose wrote:
> > > > On Fri, 2021-02-12 at 23:13 +0200, Ville Syrjälä wrote:
> > > > > On Fri, Feb 12, 2021 at 07:44:22PM +0000, Souza, Jose wrote:
> > > > > > On Fri, 2021-02-12 at 20:35 +0200, Ville Syrjälä wrote:
> > > > > > > On Fri, Feb 12, 2021 at 10:22:01AM -0800, José Roberto de Souza wrote:
> > > > > > > > Found a system were firmware/BIOS left the plane_res_b and plane_res_l
> > > > > > > > set with non-zero values for disable planes.
> > > > > > > 
> > > > > > > It pretty much happens always since the reset value is not zero.
> > > > > > > IIRC we made the state chcker pedantic enough to complain about
> > > > > > > that, so we need to clean it up.
> > > > > > 
> > > > > > Are you planning to fix it soon?
> > > > > 
> > > > > Fix what exactly? I guess you're seeing an actual problem of some sort?
> > > > 
> > > > Your comment above made me understand that you were planning to fix this plane watermark mismatches for disabled planes in other way other than what
> > > > this patch does.
> > > > Or should we proceed with this solution? 
> > > 
> > > There should be no mismatches with the current scheme.
> > > We explicitly program wms to 0 for disabled planes.
> > > 
> > 
> > It still happens when we take over the state that BIOS/firmware left.
> 
> That would seem to imply skl_wm_add_affected_planes() isn't working
> right for some reason.
> 

Reading out watermark state during initial readout fixed it:
drm/i915/display: Read planes watermarks during initial state readout


More information about the Intel-gfx mailing list