Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: igt-dev@lists.freedesktop.org,
	Matt Roper <matthew.d.roper@intel.com>,
	Ville Syrjala <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH i-g-t] intel_reg: Stop warning if register spec is not there
Date: Thu, 11 Apr 2024 17:55:30 +0300	[thread overview]
Message-ID: <87a5m054pp.fsf@intel.com> (raw)
In-Reply-To: <75oqxqfgpu2gop5zq37hctzul7ztx2r2gwigxvl2trmwomn2lz@zqcsidtq627p>

On Thu, 11 Apr 2024, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> I don't think we will be able to invest time to manually update them.

Agreed.

> I have a dream of being able to partially generate the regs/*.h file
> in xe. Maybe if we ever achieve that we can think of using the same
> source for igt.

Agreed.

> But as I said, I think we are far far away from that. What do you think
> should be done in the short/mid term?
>
> a) this patch as is
> b) keep the warning for verbosity > 0 as sugggested by others

Either as the first step is fine by me.

> c) just remove tools/registers to simplify the code. To be added back if
>     we ever figure how to autogenerate them with the same source that
>     autogenerates the kernel

I think they're still useful for deciding the contents of intel_reg
dump, for the platforms defined anyway. I wouldn't throw them away.

> d) something else?

I wouldn't object to incorporating the information in the tool at build
time. But if nobody has the time to do that, just let it be until we
have figured out a way to generate the info, if ever.

Since the decoding info is starting to be out of date, especially the
builtin stuff, maybe it should be made optional via a --decode parameter
similar to --binary, and default to off?

BR,
Jani.

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-04-11 14:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-10 23:17 [PATCH i-g-t] intel_reg: Stop warning if register spec is not there Lucas De Marchi
2024-04-11  2:12 ` ✓ CI.xeBAT: success for " Patchwork
2024-04-11  2:27 ` ✓ Fi.CI.BAT: " Patchwork
2024-04-11  8:53 ` [PATCH i-g-t] " Jani Nikula
2024-04-11 12:48   ` Lucas De Marchi
2024-04-11 13:24     ` Jani Nikula
2024-04-11 14:29       ` Lucas De Marchi
2024-04-11 14:55         ` Jani Nikula [this message]
2024-04-11 15:32           ` Lucas De Marchi
2024-04-11 10:07 ` Zbigniew Kempczyński
2024-04-11 10:10   ` Zbigniew Kempczyński
2024-04-11 13:49 ` ✗ CI.xeFULL: failure for " Patchwork
2024-04-11 14:45 ` ✗ 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=87a5m054pp.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox