linux-kernel - Re: [PATCH 1/2] drm: Add NVIDIA Tegra20 support

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] [day] [month] [year] [list]

Message-ID: <50A201DE.9090409@nvidia.com>
Date:	Tue, 13 Nov 2012 10:16:30 +0200
From:	Terje Bergström <tbergstrom@...dia.com>
To:	Thierry Reding <thierry.reding@...onic-design.de>
CC:	Dave Airlie <airlied@...hat.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] drm: Add NVIDIA Tegra20 support

On 13.11.2012 10:03, Thierry Reding wrote:
> That should be fixed with v2 I posted a few hours ago.

That's true.

> Yes, Tegra30 support will follow in a separate patch. As for IOMMU
> support it should eventually be made completely transparent, but I'm not
> opposed to adding a patch with explicit IOMMU support back in if it
> turns out that it can't be done transparently.

The trouble with this is that the generic case demands that we support
each device having a separate address space. But, on Tegra30 SMMU has
only four address spaces, so in Tegra30 case we actually end up using
the same address space for multiple devices.

Second problem is trying to avoid double mapping. With 2D acceleration,
we need support for allocating buffers, and mapping them to DC, host1x
and 2D. DMA Mapping API has a problem in that it doesn't allow just
allocating - it forces mapping the buffer to a device at the same time.
So, when 2D submit contains a reference to a dma-buf, the buffer has
already been mapped to some device, but we don't have a good way of
detecting that. We end up mapping it again, which is a performance
killer and possibly a coherence problem.

Fortunately this is all related to 2D acceleration, so we can defer both
of these problems for now.

Best regards,
Terje

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/