From: "Terje Bergström" <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Cc: "thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org"
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Arto Merilainen
<amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCHv3 0/7] Support for Tegra 2D hardware
Date: Thu, 13 Dec 2012 17:33:39 +0200 [thread overview]
Message-ID: <50C9F553.5030401@nvidia.com> (raw)
In-Reply-To: <1355410991.11327.12.camel@selen>
On 13.12.2012 17:03, Lucas Stach wrote:
> You are still doing the allocation the IMHO wrong way around. I thought
> we agreed to do all the allocations in host1x, which obviously means not
> using the cma_gem_helpers anymore, but introducing a new native host1x
> object to back GEM/V4L/whatever objects. IMHO the current approach is a
> clear layering violation and makes proper IOMMU support a lot harder. It
> would also allow to get rid of all the indirections and ifdefs in host1x
> memmgr, as host1x would only have to deal with it's native objects.
>
> All the complexity of converting host1x to GEM objects should be located
> in tegradrm and not be scattered between different modules.
>
> Did you leave this out on purpose in this version of the patchset?
Forgot to mention that, as IOMMU and consequently the "proper"
allocation support was planned as a follow-up. I wanted to keep the
scope of this set as small as possible.
The plan we agreed on still holds.
Terje
>> * tegradrm has a global variable. Plan was to hide that behind a
>> virtual device, and use that as DRM root device. That plan went
>> bad once the FB CMA helper used the device for trying to allocate
>> memory.
> See above, we should get rid of the helpers and do all allocations
> within host1x.
I noticed that IOMMU and not using the CMA FB helper is now exynos
managed to do this.
Terje
WARNING: multiple messages have this Message-ID (diff)
From: "Terje Bergström" <tbergstrom@nvidia.com>
To: Lucas Stach <dev@lynxeye.de>
Cc: "thierry.reding@avionic-design.de"
<thierry.reding@avionic-design.de>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Arto Merilainen <amerilainen@nvidia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv3 0/7] Support for Tegra 2D hardware
Date: Thu, 13 Dec 2012 17:33:39 +0200 [thread overview]
Message-ID: <50C9F553.5030401@nvidia.com> (raw)
In-Reply-To: <1355410991.11327.12.camel@selen>
On 13.12.2012 17:03, Lucas Stach wrote:
> You are still doing the allocation the IMHO wrong way around. I thought
> we agreed to do all the allocations in host1x, which obviously means not
> using the cma_gem_helpers anymore, but introducing a new native host1x
> object to back GEM/V4L/whatever objects. IMHO the current approach is a
> clear layering violation and makes proper IOMMU support a lot harder. It
> would also allow to get rid of all the indirections and ifdefs in host1x
> memmgr, as host1x would only have to deal with it's native objects.
>
> All the complexity of converting host1x to GEM objects should be located
> in tegradrm and not be scattered between different modules.
>
> Did you leave this out on purpose in this version of the patchset?
Forgot to mention that, as IOMMU and consequently the "proper"
allocation support was planned as a follow-up. I wanted to keep the
scope of this set as small as possible.
The plan we agreed on still holds.
Terje
>> * tegradrm has a global variable. Plan was to hide that behind a
>> virtual device, and use that as DRM root device. That plan went
>> bad once the FB CMA helper used the device for trying to allocate
>> memory.
> See above, we should get rid of the helpers and do all allocations
> within host1x.
I noticed that IOMMU and not using the CMA FB helper is now exynos
managed to do this.
Terje
next prev parent reply other threads:[~2012-12-13 15:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-13 14:04 [PATCHv3 0/7] Support for Tegra 2D hardware Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 14:04 ` [PATCHv3 1/7] gpu: host1x: Add host1x driver Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 14:04 ` [PATCHv3 2/7] gpu: host1x: Add syncpoint wait and interrupts Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 14:04 ` [PATCHv3 3/7] gpu: host1x: Add channel support Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 14:04 ` [PATCHv3 4/7] gpu: host1x: Add debug support Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 15:23 ` Joe Perches
2012-12-13 15:23 ` Joe Perches
2012-12-17 14:01 ` Terje Bergström
2012-12-17 14:01 ` Terje Bergström
2012-12-17 17:04 ` Joe Perches
2012-12-13 14:04 ` [PATCHv3 5/7] drm: tegra: Remove redundant host1x Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 14:04 ` [PATCHv3 6/7] ARM: tegra: Add board data and 2D clocks Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 14:04 ` [PATCHv3 7/7] drm: tegra: Add gr2d device Terje Bergstrom
2012-12-13 14:04 ` Terje Bergstrom
2012-12-13 15:03 ` [PATCHv3 0/7] Support for Tegra 2D hardware Lucas Stach
2012-12-13 15:33 ` Terje Bergström [this message]
2012-12-13 15:33 ` Terje Bergström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50C9F553.5030401@nvidia.com \
--to=tbergstrom-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.