All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/9] drm/i915: Bump DSL linemask to 20 bits
Date: Wed, 26 Jan 2022 16:34:04 +0200	[thread overview]
Message-ID: <87ilu6zhur.fsf@intel.com> (raw)
In-Reply-To: <YZd8yaUEE4tca+D8@intel.com>

On Fri, 19 Nov 2021, Ville Syrjälä <ville.syrjala@linux.intel.com> 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@linux.intel.com>
>> > 
>> > 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@intel.com>


-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-01-26 14:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12 19:38 [Intel-gfx] [PATCH 0/9] drm/i915: Register define cleanups Ville Syrjala
2021-11-12 19:38 ` [Intel-gfx] [PATCH 1/9] drm/i915: Bump DSL linemask to 20 bits Ville Syrjala
2021-11-15 19:05   ` Rodrigo Vivi
2021-11-19 10:30     ` Ville Syrjälä
2022-01-26 14:34       ` Jani Nikula [this message]
2021-11-12 19:38 ` [Intel-gfx] [PATCH 2/9] drm/i915: Clean up PIPEMISC register defines Ville Syrjala
2021-11-15 19:12   ` Rodrigo Vivi
2021-11-19 10:24     ` Ville Syrjälä
2021-11-24 10:18       ` Jani Nikula
2022-01-26 14:36   ` Jani Nikula
2021-11-12 19:38 ` [Intel-gfx] [PATCH 3/9] drm/i915: Clean up SKL_BOTTOM_COLOR defines Ville Syrjala
2022-01-26 14:21   ` Jani Nikula
2021-11-12 19:38 ` [Intel-gfx] [PATCH 4/9] drm/i915: Clean up PIPECONF bit defines Ville Syrjala
2022-01-26 14:31   ` Jani Nikula
2021-11-12 19:38 ` [Intel-gfx] [PATCH 5/9] drm/i915: Clean up PCH_TRANSCONF/TRANS_DP_CTL " Ville Syrjala
2022-01-26 14:40   ` Jani Nikula
2021-11-12 19:38 ` [Intel-gfx] [PATCH 6/9] drm/i915: Clean up PIPESRC defines Ville Syrjala
2022-01-26 14:42   ` Jani Nikula
2022-01-26 21:39     ` Ville Syrjälä
2021-11-12 19:38 ` [Intel-gfx] [PATCH 7/9] drm/i915: Clean up CRC register defines Ville Syrjala
2021-11-15 19:07   ` Rodrigo Vivi
2021-11-12 19:38 ` [Intel-gfx] [PATCH 8/9] drm/i915: Clean up DPINVGTT/VLV_DPFLIPSTAT bits Ville Syrjala
2021-11-15 19:05   ` Rodrigo Vivi
2021-11-12 19:38 ` [Intel-gfx] [PATCH 9/9] drm/i915: Clean up FPGA_DBG/CLAIM_ER bits Ville Syrjala
2021-11-15 19:05   ` Rodrigo Vivi
2021-11-12 20:40 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Register define cleanups Patchwork
2021-11-12 20:46 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-11-12 21:12 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-12 23:41 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ilu6zhur.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.