On Fri, 19 Nov 2021, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Mon, Nov 15, 2021 at 02:05:00PM -0500, Rodrigo Vivi wrote: >> On Fri, Nov 12, 2021 at 09:38:05PM +0200, Ville Syrjala wrote: >> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> > >> > Since tgl PIPE_DSL has 20 bits for the scanline. Let's bump our >> > definition to match. And while at it let's also add the define >> > for the current field readback. >> > >> > We can also get rid of the gen2 vs. gen3+ nonsense since none >> > of the extra bits ever did anything and just always read >> > as zero. >> >> You are stepping over reserved bits on older platforms here. >> >> I understand that must probably hw is not using this for anything >> and the reads are only zero. But I'm always afraid of opening >> precedence for this kind of assumptions and end up stepping >> over some reserved bit that hw is using for something else >> but not documented. > > We do this in other places too in order to keep the code > simple. I think it's fine for cases where all old platforms > had a smaller bitfield which is extended in later platforms. > That is, assuming all the bits were unused (and read as zero) > in the old platforms, which is the case here. > > The thing we probably shouldn't do is make the bitfield larger > proactively for future platforms since we can't know if some of > the currently unused bits might end up being used for something > else in the future. > > I really hope we don't have any undocumented bits anywhere since > those can screw us up in a lot more ways than this. If we do find > any undocuemnted bits we really need to file bspec issues for those. I guess I'd record some of this in the commit message while applying, in case this blows up. Other than that, Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> -- Jani Nikula, Intel Open Source Graphics Center