From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1422742AbdKRKti (ORCPT <rfc822;w@1wt.eu>);
        Sat, 18 Nov 2017 05:49:38 -0500
Received: from mail-wm0-f51.google.com ([74.125.82.51]:46880 "EHLO
        mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752116AbdKRKta (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 18 Nov 2017 05:49:30 -0500
X-Google-Smtp-Source: AGs4zMbb/1Y5PCb+0sSz6dJD7u2nRINRglLUj7uTLtxaP31wyWYqkseeY66qG88chjI+XJAwsaAASQ==
Subject: Re: [git pull] drm for v4.15
To: christian.koenig@amd.com,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>
References: <CAPM=9tz-HT7ynGrzXwtnaDcj+0MumLBj1Z8VUB+v6W=9P_eaNA@mail.gmail.com>
 <CA+55aFzCfbqEn=VSn8rhcLm9sTqaRTCQ3AgxhZA2xuP-P3QFBA@mail.gmail.com>
 <CAPM=9txQo2yAe1nwUtyYETbGdgjY9GHgmXYYC=1ojyydUb72HQ@mail.gmail.com>
 <26729c32-cfd6-82e0-b370-a46ca951adea@gmail.com>
 <CA+55aFz4ZeXeu_bfiKGLJhqa8Z2zsvL9Xd+oBSYo-gsdLSSGfA@mail.gmail.com>
 <29dd45a7-4a58-ed71-e6d4-1cd4bfc69ee5@amd.com>
 <CA+55aFxj9v-ZefhLO2EpdUY58ggCHF6ON5fW0MEb==zZBR9=ag@mail.gmail.com>
 <c248101e-91ba-e451-b648-3d504befd29d@gmail.com>
From: =?UTF-8?Q?Nicolai_H=c3=a4hnle?= <nhaehnle@gmail.com>
Message-ID: <d4823dd9-56e7-6b8c-4e2c-d7b48c7413c1@gmail.com>
Date: Sat, 18 Nov 2017 11:49:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <c248101e-91ba-e451-b648-3d504befd29d@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 17.11.2017 20:18, Christian König wrote:
> The obvious alternative which we are working on for a few years now is 
> to improve the input data we get from the hardware people.
> 
> In other words instead of getting a flat list of registers we want the 
> information about where and how many times a hardware block was 
> instantiated.
> 
> But getting that proved much more difficult than we thought and yes we 
> are working on that for multiple years now.

Well, the good news is that at least for the gfx registers, I actually 
have a proof-of-concept script that extracts the required information 
from the hardware sources. Generating e.g. a CB_COLOR_INFO(x) macro 
instead of CB_COLORx_INFO defines from that is not that hard :)

The real challenge is getting this integrated into the right processes 
so we don't have as much of a maintenance burden.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.