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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
