linux-kernel - Re: [PATCH] drm/vc4: Add support for SAND modifier.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPj87rNtcN0PDFViJB_NOVzUeLSWKe9smnQx7RSXwBR1+nm__w@mail.gmail.com>
Date:   Wed, 14 Mar 2018 11:08:54 +0000
From:   Daniel Stone <daniel@...ishbar.org>
To:     Eric Anholt <eric@...olt.net>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        Dave Stevenson <dave.stevenson@...pberrypi.org>,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Daniel Stone <daniels@...labora.com>
Subject: Re: [PATCH] drm/vc4: Add support for SAND modifier.

Hey Eric,

On 3 March 2018 at 01:34, Eric Anholt <eric@...olt.net> wrote:
> Ccing a couple of folks who are likely to have opinions about
> drm_fourcc.h additions (Do we have enough docs?  Are the macros OK?),
> and Bootlin who are likely reviewers.
>
> The plan is to use these modifiers in VC4 GL imports as well, and for
> buffers coming from the v4l2 mmal camera driver.  You can find a demo
> using this in KMS planes at
> https://github.com/anholt/drm_mmal/commit/sand for now.

I had a dig through and this seems like the most sensible thing to do
if you have a reasonable variety of tile heights. If you only see a
couple of combinations in the wild, then hardcoding them as separate
modifiers might make things easier than hiving off 24 bits. If you do
keep the split though, and especially if you're envisioning future
flexible tile formats, maybe something like an 8 code / 48 params
split would make more sense.

Either way, those are just my opinions (you did ask), and I don't see
anything really objectionable, so if you think that's a good split
then this is:
Acked-by: Daniel Stone <daniels@...labora.com>

Cheers,
Daniel