On Thu, Oct 14, 2021 at 12:32:55AM +0300, Imre Deak wrote: > On Wed, Oct 13, 2021 at 11:45:33PM +0300, Ville Syrjälä wrote: > > On Wed, Oct 13, 2021 at 11:27:02PM +0300, Ville Syrjälä wrote: > > > On Thu, Oct 07, 2021 at 11:35:15PM +0300, Imre Deak wrote: > > > > Future platforms change the location of CCS control planes in CCS > > > > framebuffers, so add intel_fb_is_rc_ccs_ctrl_plane() to query for these > > > > > > Don't we use the term 'ccs_plane' everywhere else? > > > > > > > planes independently of the platform. This function can be used > > > > everywhere instead of is_ccs_plane() (or is_ccs_plane() && !cc_plane()), > > > > since all the callers are only interested in control planes (and not CCS > > > > color-clear planes). > > > > Hmm. I guess you're changing the terminology across the board? > > If it's used consistently then no objections from me. > > ccs_plane has been used as a generic term for both the "control" and the > cc plane, or at least I thought of it as such. The official definition I think is: CCS == color control surface So in terms of modifier naming I suppose I tend to think of it like this: modifier name has CCS -> color control surface is present modifier name has CC -> clear color is present But if we want to make the distinction somehow stronger I was thinking maybe ccs_aux vs. ccs_cc. But dunno if that just ends up being more confusing since AUX_DIST is also used for planar scanout on skl/etc. Or another way to make it more clear would be to drop the "ccs" part from the is_ccs_cc_plane() or whatever. But is_cc_plane() is perhaps also pretty confusing. So could expand it to full on is_clear_color_plane()? Shrug. Plenty of different color paint for this one available I think. -- Ville Syrjälä Intel
