[PATCHv5,RESEND 0/8] Support for Tegra 2D hardware

Terje Bergström tbergstrom at nvidia.com
Fri Feb 1 03:29:16 PST 2013


On 15.01.2013 03:43, Terje Bergstrom wrote:
> This set of patches adds support for Tegra20 and Tegra30 host1x and
> 2D. It is based on linux-next-20130114. The set was regenerated with
> git format-patch -M.
> 
> The fifth version merges DRM and host1x drivers into one driver. This
> allowed moving include/linux/host1x.h back into the driver and removed
> the need for a dummy platform device. This version also uses the code
> from tegradrm driver almost as is, so there are a lot less actual code
> changes.
> 
> This patch set does not have the host1x allocator, but it uses CMA
> helpers for memory management.
> 
> host1x is the driver that controls host1x hardware. It supports
> host1x command channels, synchronization, and memory management. It
> is sectioned into logical driver under drivers/gpu/host1x and
> physical driver under drivers/host1x/hw. The physical driver is
> compiled with the hardware headers of the particular host1x version.
> 
> The hardware units are described (briefly) in the Tegra2 TRM. Wiki
> page https://gitorious.org/linux-tegra-drm/pages/Host1xIntroduction
> also contains a short description of the functionality.
> 
> The patch set merges tegradrm into host1x and adds 2D driver, which
> uses host1x channels and sync points. The patch set also adds user
> space API to tegradrm for accessing host1x and 2D.

Could you please have a look at the patch set? Are you expecting me to
do something? I got barely any response (only one from Stephen), which
means host1x upstreaming is completely stalled.

Lucas mentioned in another thread that he'd need to review also libdrm,
and then there's the host1x allocator issue which Lucas wanted to create
but hasn't had time.

Could we postpone the host1x allocator to a later patchset? It shouldn't
be a merge blocked, as it shouldn't have an API impact, and it is
strictly needed with IOMMU support. The DRM CMA helper is already working.

If the amount of code related to channels are the problem, should we
scope this patch set to include only sync point support and drop
channels, debug and 2D driver? That way we could get at least the basic
code rearrangement done.

Terje


More information about the dri-devel mailing list