[PATCH i-g-t] intel_reg: Stop warning if register spec is not there

[Lucas De Marchi]

On Thu, Apr 11, 2024 at 04:24:43PM +0300, Jani Nikula wrote:
>On Thu, 11 Apr 2024, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>> On Thu, Apr 11, 2024 at 11:53:03AM +0300, Jani Nikula wrote:
>>>On Wed, 10 Apr 2024, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>>>> Stop suffering when using igt from the git checkout, which is the case
>>>> for all/most developers.
>>>>
>>>> 	$ sudo ./build/tools/intel_reg write 0x2358 0xdeadbeef
>>>> 	Warning: stat '/usr/local/share/igt-gpu-tools/registers' failed: No such file or directory. Using builtin register spec.
>>>>
>>>> Pretty annoying when you have a bunch of commands to run and don't want
>>>> to simply ignore stderr.  Keep the other warnings as if the file is
>>>> there and can't be read for some reason, it's good to give a warning.
>>>> However if the file simply isn't there, let it pass.
>>>
>>>The TL;DR is,
>>>
>>>Acked-by: Jani Nikula <jani.nikula at intel.com>
>>>
>>>---
>>>
>>>We have the "register specs" in plain text files so that anyone could
>>>update them at runtime without building the source. And conceivably they
>>>could be generated from a more authoritative source. It would be nice if
>>>we could incorporate the info to the binary at build time as the builtin
>>>register specs (so no data dir lookups at all), but also be able to
>>>override them e.g. using a command-line parameter if the user wishes.
>>>
>>>I don't think that would even be so hard. But it would arguably be a bit
>>>wasted effort as long as the register files under tools/registers/
>>>aren't updated for newer platforms. (The current builtin register specs
>>>are completely out of date.)
>>
>> I don't really get why one would want the tools/registers actually. When
>> I'm using intel_reg I'm already working on a very low level interface
>> with the hardware and can simply pass/read the raw offsets.
>
>Something we wanted but never materialized was decoding register
>contents, like the builtin decoding does. But I think with the pace of
>registers added and meanings changing from platform to platform, etc,
>with no automated import of the specs, it was just too laborous by hand.
>
>And there's also the dumping, and it's kind of platform specific what
>should be included. I think that's where the tools/registers files
>originated.

I don't think we will be able to invest time to manually update them.
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.

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
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
d) something else?

thanks
Lucas De Marchi