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.
next prev 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