public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"Nicolai Hähnle" <nhaehnle@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [git pull] drm for v4.15
Date: Fri, 17 Nov 2017 19:14:23 +0100	[thread overview]
Message-ID: <29dd45a7-4a58-ed71-e6d4-1cd4bfc69ee5@amd.com> (raw)
In-Reply-To: <CA+55aFz4ZeXeu_bfiKGLJhqa8Z2zsvL9Xd+oBSYo-gsdLSSGfA@mail.gmail.com>

First of all I can certainly agree with everything said so far, so just 
skipping to the technical problem.

Am 17.11.2017 um 17:57 schrieb Linus Torvalds:
>
> People say "it's a ton of work to do it by hand". They'd be right. I'm
> not saying you should do it by hand. But "automation" does not always
> need to mean "completely mindlessly stupid" either.

Taking an example from the AMD headers why this automation is more 
tricky than it sounds in the first place: Look at the 
mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.

Register 0-7 are consecutive and so could be perfectly addressable with 
an index, but register 8-15 aren't and so we always end with logic like 
if(i<8) ... else ....

The rational from the hardware guys is obvious that they initially had 
only 8 and on a later hardware generation extended that to 16 registers.

Patterns like that repeat all over the place and are not limited to AMD 
at all.


We could write up hand written rules to sanitize all of that, but then 
we are back to "automatically" creating the headers by hand.

When you have to maintain 10+ years of hardware generations where 
sometimes registers headers even need to be regenerated from the 
database then that is something which won't fly either.


Certainly not saying that this is a bad idea, but we simply need better 
tools for that which also have 100% reproducible results.

Ideas welcome,
Christian.

  parent reply	other threads:[~2017-11-17 18:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16  2:34 [git pull] drm for v4.15 Dave Airlie
2017-11-16  4:59 ` Linus Torvalds
2017-11-16 13:57   ` Rob Clark
2017-11-16 17:17   ` Michel Dänzer
2017-11-16 20:57   ` Dave Airlie
2017-11-16 21:05     ` Linus Torvalds
2017-11-17 12:51     ` Nicolai Hähnle
2017-11-17 16:57       ` Linus Torvalds
2017-11-17 17:19         ` Lukas Wunner
2017-11-17 17:24           ` Linus Torvalds
2017-11-17 18:14         ` Christian König [this message]
2017-11-17 18:55           ` Linus Torvalds
2017-11-17 19:18             ` Christian König
2017-11-18 10:49               ` Nicolai Hähnle

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=29dd45a7-4a58-ed71-e6d4-1cd4bfc69ee5@amd.com \
    --to=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhaehnle@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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