[PATCH 01/12] drm/i915: Indicate which pipe failed the fastset check overall

Jani Nikula jani.nikula at linux.intel.com
Mon Feb 26 15:35:51 UTC 2024


On Mon, 26 Feb 2024, Andy Shevchenko <andriy.shevchenko at linux.intel.com> wrote:
> On Mon, Feb 26, 2024 at 04:57:58PM +0200, Jani Nikula wrote:
>> On Fri, 23 Feb 2024, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
>> > On Thu, Feb 22, 2024 at 04:46:12PM -0500, Rodrigo Vivi wrote:
>
> ...
>
>> > I think the proper solution would be to have actually
>> > sensible conversion specifiers in the format string.
>> > So instead of %<set of random characters> we'd have something
>> > more like %{drm_crtc} (or whatever color you want to throw
>> > on that particular bikeshed).
>> 
>> Personally I suck at remembering even the standard printf conversion
>> specifiers, let alone all the kernel extensions. I basically have to
>> look them up every time. I'd really love some %{name} format for named
>> pointer things. And indeed preferrably without the %p. Just %{name}.
>
> It will become something like %{name[:subextensions]}, where subextensions
> is what we now have with different letters/numbers after %pX (X is a letter
> which you proposed to have written as name AFAIU).

Thanks, I appreciate it, a lot!

But could you perhaps try to go with just clean %{name} only instead of
adding [:subextensions] right away, please?

I presume the suggestion comes from an implementation detail, and I
guess it would be handy to reuse the current implementation for
subextension.

For example, %pb -> %{bitmap} and %pbl -> %{bitmap:l}. But really I
think the better option would be for the latter to become, say,
%{bitmap-list}. The goal here is to make them easy to remember and
understand, without resorting to looking up the documentation!


BR,
Jani.

>
>> And then we could discuss adding support for drm specific things. I
>> guess one downside is that the functions to do this would have to be in
>> vsprintf.c instead of drm. Unless we add some code in drm for this
>> that's always built-in.

-- 
Jani Nikula, Intel


More information about the Intel-gfx mailing list