Re: [Freedreno] [PATCH 12/12] drm/msm/adreno: Switch to chip-id for identifying GPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27/07/2023 00:44, Rob Clark wrote:
On Wed, Jul 26, 2023 at 2:38 PM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:

On 27/07/2023 00:37, Rob Clark wrote:
On Thu, Jul 6, 2023 at 8:45 PM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:

On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark <robdclark@xxxxxxxxxxxx>

    /* Helper for formating the chip_id in the way that userspace tools like
     * crashdec expect.
     */
    #define ADRENO_CHIPID_FMT "u.%u.%u.%u"
-#define ADRENO_CHIPID_ARGS(_r) (_r).core, (_r).major, (_r).minor, (_r).patchid
+#define ADRENO_CHIPID_ARGS(_c) \
+     (((_c) >> 24) & 0xff), \
+     (((_c) >> 16) & 0xff), \
+     (((_c) >> 8)  & 0xff), \
+     ((_c) & 0xff)

So, we still have some meaning for chipid?

Only enough to do the inverse of what userspace does when parsing
devcoredump to construct chip-id.  Basically it is just a different
way to represent a 32b #

What about passing it in the direct form? The macro adds assumptions.

It is uabi

I wouldn't call it adding assumptions as much as just a funny way to
format a number.  In some cases it might work out to something that
vaguely resembles a marketing name (6.3.0.2), in other cases it won't
(12.34.56.78).. it's just formatting a 32b # to match the way existing
userspace parses it

I see. Sounds fine then.

--
With best wishes
Dmitry




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux