linux-kernel - Re: [RFC v2 0/8] Support for Tegra 2D hardware

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: <20121201144512.GA18209@avionic-0098.adnet.avionic-design.de>
Date:	Sat, 1 Dec 2012 15:45:12 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Terje Bergstrom <tbergstrom@...dia.com>
Cc:	linux-tegra@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 0/8] Support for Tegra 2D hardware

On Mon, Nov 26, 2012 at 03:19:06PM +0200, Terje Bergstrom wrote:
[...]
> The patch set also adds user space API to tegradrm for accessing
> host1d and 2D. We are preparing also patches to libdrm, but they are
> not yet in condition that they could be sent out.

I did some prototyping on how a libdrm API could look like a few weeks
back. I should clean the patches up some and push them to a public
repository or to the mailing lists for review.

There isn't actually much more than a bit of framework along with two
IOCTLs that allow creating and looking up a Tegra-specific GEM. The
related kernel patches aren't available anywhere since I didn't deem
them ready yet. At that time I wasn't even sure if we'd need special
allocations other than what the dumb BO infrastructure provides. They
implement some parts of what you've implemented in this series as well,
with some slight differences.

Currently these still use the CMA-backed GEM objects but it should be
easy to switch to something backed by the host1x infrastructure once
that's in good shape.

While I can't find the quote right now, I seem to remember that you said
at some point that you were planning on adding some 2D acceleration bits
to libdrm. I don't think that's the right place. That code should rather
go into the DDX. libdrm should instead provide a thin layer on top of
the DRM IOCTLs to manage buffers and submit command streams. I hope I
can finish the cleanup of my libdrm patches over the weekend and push
them out so this may become clearer. Maybe I can even get the
corresponding kernel patches pushed out.

Thierry

Content of type "application/pgp-signature" skipped