From: "Terje Bergström" <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org"
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
"airlied-cv59FeDIM0c@public.gmane.org"
<airlied-cv59FeDIM0c@public.gmane.org>,
"dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org"
<dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCHv4 0/8] Support for Tegra 2D hardware
Date: Wed, 2 Jan 2013 11:42:30 +0200 [thread overview]
Message-ID: <50E40106.4020406@nvidia.com> (raw)
In-Reply-To: <50DD6311.9000002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 28.12.2012 11:14, Mark Zhang wrote:
> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
> index a936902..c3ded60 100644
> --- a/drivers/gpu/drm/tegra/gr2d.c
> +++ b/drivers/gpu/drm/tegra/gr2d.c
> @@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
> *context,
> if (err)
> goto fail;
>
> + /* We define CMA as an temporary solution in host1x driver.
> + That's also why we have a CMA kernel config in it.
> + But seems here, in tegradrm, we hardcode the CMA here.
> + So what do you do when host1x change to IOMMU?
> + Do we also need to define a CMA config in tegradrm
> driver,
> + then after host1x changes to IOMMU, we add another IOMMU
> + config in tegradrm? Or we should invent another more
> + generic wrapper layer here? */
> cmdbuf.mem = handle_cma_to_host1x(drm, file_priv,
> cmdbuf.mem);
Lucas is working on host1x allocator, so let's defer this comment until
we have Lucas' code.
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index cc8ca2f..0867b72 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -82,6 +82,26 @@ struct host1x_job *host1x_job_alloc(struct
> host1x_channel *ch,
> mem += num_unpins * sizeof(dma_addr_t);
> job->pin_ids = num_unpins ? mem : NULL;
>
> + /* I think this is a somewhat ugly design.
> + Actually "addr_phys" is consisted by "reloc_addr_phys" and
> + "gather_addr_phys".
> + Why don't we just declare "reloc_addr_phys" and
> "gather_addr_phys"?
> + In current design, let's say if one nvhost newbie changes the
> order
> + of these 2 blocks of code in function "pin_job_mem":
> +
> + for (i = 0; i < job->num_relocs; i++) {
> + struct host1x_reloc *reloc = &job->relocarray[i];
> + job->pin_ids[count] = reloc->target;
> + count++;
> + }
> +
> + for (i = 0; i < job->num_gathers; i++) {
> + struct host1x_job_gather *g = &job->gathers[i];
> + job->pin_ids[count] = g->mem_id;
> + count++;
> + }
> +
> + Then likely something weird occurs... */
We do this because this way we can implement batch pinning of memory
handles. This way we can decrease memory handle management a lot as we
need to do locking only once per submit.
Decreasing memory management overhead is really important, because in
complex graphics cases, there are might be a hundreds of buffer
references per submit, and several submits per frame. Any extra overhead
relates directly to reduced performance.
> job->reloc_addr_phys = job->addr_phys;
> job->gather_addr_phys = &job->addr_phys[num_relocs];
>
> @@ -252,6 +272,10 @@ static int do_relocs(struct host1x_job *job,
> }
> }
>
> + /* I have question here. Does this mean the address info
> + which need to be relocated(according to the libdrm codes,
> + seems this address is "0xDEADBEEF") always staying at the
> + beginning of a page? */
> __raw_writel(
> (job->reloc_addr_phys[i] +
> reloc->target_offset) >> reloc->shift,
No - the slot can be anywhere. That's why we have cmdbuf_offset in the
reloc struct.
> @@ -565,6 +589,7 @@ int host1x_job_pin(struct host1x_job *job, struct
> platform_device *pdev)
> }
> }
>
> + /* if (host1x_firewall && !err) { */
> if (host1x_firewall) {
> err = copy_gathers(job, pdev);
> if (err) {
Will add.
> @@ -573,6 +598,9 @@ int host1x_job_pin(struct host1x_job *job, struct
> platform_device *pdev)
> }
> }
>
> +/* Rename this label to "out" or something else.
> + Because if everything goes right, the codes under this label also
> + get executed. */
> fail:
> wmb();
Will do.
>
> diff --git a/drivers/gpu/host1x/memmgr.c b/drivers/gpu/host1x/memmgr.c
> index f3954f7..bb5763d 100644
> --- a/drivers/gpu/host1x/memmgr.c
> +++ b/drivers/gpu/host1x/memmgr.c
> @@ -156,6 +156,9 @@ int host1x_memmgr_pin_array_ids(struct
> platform_device *dev,
> count, &unpin_data[pin_count],
> phys_addr);
>
> + /* I don't think the current "host1x_cma_pin_array_ids"
> + is able to return a negative value. So this "if" doesn't
> + make sense...*/
> if (cma_count < 0) {
> /* clean up previous handles */
> while (pin_count) {
It should return negative in case of error.
Terje
WARNING: multiple messages have this Message-ID (diff)
From: "Terje Bergström" <tbergstrom@nvidia.com>
To: Mark Zhang <nvmarkzhang@gmail.com>
Cc: "thierry.reding@avionic-design.de"
<thierry.reding@avionic-design.de>,
"airlied@linux.ie" <airlied@linux.ie>,
"dev@lynxeye.de" <dev@lynxeye.de>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv4 0/8] Support for Tegra 2D hardware
Date: Wed, 2 Jan 2013 11:42:30 +0200 [thread overview]
Message-ID: <50E40106.4020406@nvidia.com> (raw)
In-Reply-To: <50DD6311.9000002@gmail.com>
On 28.12.2012 11:14, Mark Zhang wrote:
> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
> index a936902..c3ded60 100644
> --- a/drivers/gpu/drm/tegra/gr2d.c
> +++ b/drivers/gpu/drm/tegra/gr2d.c
> @@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
> *context,
> if (err)
> goto fail;
>
> + /* We define CMA as an temporary solution in host1x driver.
> + That's also why we have a CMA kernel config in it.
> + But seems here, in tegradrm, we hardcode the CMA here.
> + So what do you do when host1x change to IOMMU?
> + Do we also need to define a CMA config in tegradrm
> driver,
> + then after host1x changes to IOMMU, we add another IOMMU
> + config in tegradrm? Or we should invent another more
> + generic wrapper layer here? */
> cmdbuf.mem = handle_cma_to_host1x(drm, file_priv,
> cmdbuf.mem);
Lucas is working on host1x allocator, so let's defer this comment until
we have Lucas' code.
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index cc8ca2f..0867b72 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -82,6 +82,26 @@ struct host1x_job *host1x_job_alloc(struct
> host1x_channel *ch,
> mem += num_unpins * sizeof(dma_addr_t);
> job->pin_ids = num_unpins ? mem : NULL;
>
> + /* I think this is a somewhat ugly design.
> + Actually "addr_phys" is consisted by "reloc_addr_phys" and
> + "gather_addr_phys".
> + Why don't we just declare "reloc_addr_phys" and
> "gather_addr_phys"?
> + In current design, let's say if one nvhost newbie changes the
> order
> + of these 2 blocks of code in function "pin_job_mem":
> +
> + for (i = 0; i < job->num_relocs; i++) {
> + struct host1x_reloc *reloc = &job->relocarray[i];
> + job->pin_ids[count] = reloc->target;
> + count++;
> + }
> +
> + for (i = 0; i < job->num_gathers; i++) {
> + struct host1x_job_gather *g = &job->gathers[i];
> + job->pin_ids[count] = g->mem_id;
> + count++;
> + }
> +
> + Then likely something weird occurs... */
We do this because this way we can implement batch pinning of memory
handles. This way we can decrease memory handle management a lot as we
need to do locking only once per submit.
Decreasing memory management overhead is really important, because in
complex graphics cases, there are might be a hundreds of buffer
references per submit, and several submits per frame. Any extra overhead
relates directly to reduced performance.
> job->reloc_addr_phys = job->addr_phys;
> job->gather_addr_phys = &job->addr_phys[num_relocs];
>
> @@ -252,6 +272,10 @@ static int do_relocs(struct host1x_job *job,
> }
> }
>
> + /* I have question here. Does this mean the address info
> + which need to be relocated(according to the libdrm codes,
> + seems this address is "0xDEADBEEF") always staying at the
> + beginning of a page? */
> __raw_writel(
> (job->reloc_addr_phys[i] +
> reloc->target_offset) >> reloc->shift,
No - the slot can be anywhere. That's why we have cmdbuf_offset in the
reloc struct.
> @@ -565,6 +589,7 @@ int host1x_job_pin(struct host1x_job *job, struct
> platform_device *pdev)
> }
> }
>
> + /* if (host1x_firewall && !err) { */
> if (host1x_firewall) {
> err = copy_gathers(job, pdev);
> if (err) {
Will add.
> @@ -573,6 +598,9 @@ int host1x_job_pin(struct host1x_job *job, struct
> platform_device *pdev)
> }
> }
>
> +/* Rename this label to "out" or something else.
> + Because if everything goes right, the codes under this label also
> + get executed. */
> fail:
> wmb();
Will do.
>
> diff --git a/drivers/gpu/host1x/memmgr.c b/drivers/gpu/host1x/memmgr.c
> index f3954f7..bb5763d 100644
> --- a/drivers/gpu/host1x/memmgr.c
> +++ b/drivers/gpu/host1x/memmgr.c
> @@ -156,6 +156,9 @@ int host1x_memmgr_pin_array_ids(struct
> platform_device *dev,
> count, &unpin_data[pin_count],
> phys_addr);
>
> + /* I don't think the current "host1x_cma_pin_array_ids"
> + is able to return a negative value. So this "if" doesn't
> + make sense...*/
> if (cma_count < 0) {
> /* clean up previous handles */
> while (pin_count) {
It should return negative in case of error.
Terje
next prev parent reply other threads:[~2013-01-02 9:42 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 11:39 [PATCHv4 0/8] Support for Tegra 2D hardware Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 1/8] gpu: host1x: Add host1x driver Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 2/8] gpu: host1x: Add syncpoint wait and interrupts Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 3/8] gpu: host1x: Add channel support Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-4-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-22 4:17 ` Steven Rostedt
2012-12-22 4:17 ` Steven Rostedt
[not found] ` <1356149848.5896.124.camel-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
2013-01-02 9:31 ` Terje Bergström
2013-01-02 9:31 ` Terje Bergström
2013-01-02 7:40 ` Mark Zhang
2013-01-02 7:40 ` Mark Zhang
2013-01-02 9:31 ` Terje Bergström
[not found] ` <50E3FE8C.8000309-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-02 9:31 ` Mark Zhang
2013-01-02 9:31 ` Mark Zhang
[not found] ` <50E3FE57.5070702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-02 9:43 ` Terje Bergström
2013-01-02 9:43 ` Terje Bergström
2012-12-21 11:39 ` [PATCHv4 4/8] gpu: host1x: Add debug support Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 7/8] drm: tegra: Add gr2d device Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-1-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 11:39 ` [PATCHv4 5/8] drm: tegra: Remove redundant host1x Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-6-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 14:36 ` Thierry Reding
2012-12-21 14:36 ` Thierry Reding
2012-12-22 6:50 ` Terje Bergström
[not found] ` <50D55820.7030302-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-25 5:25 ` Stephen Warren
2012-12-25 5:25 ` Stephen Warren
2012-12-28 21:21 ` Thierry Reding
2012-12-31 6:43 ` Terje Bergström
2012-12-31 6:43 ` Terje Bergström
[not found] ` <20121221143614.GA16167-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2013-01-03 17:58 ` Terje Bergström
2013-01-03 17:58 ` Terje Bergström
2012-12-21 11:39 ` [PATCHv4 6/8] ARM: tegra: Add board data and 2D clocks Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 8/8] gpu: host1x: Register DRM dummy device Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-9-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 13:53 ` Lucas Stach
2012-12-21 13:53 ` Lucas Stach
2012-12-21 14:09 ` Thierry Reding
2012-12-21 14:09 ` Thierry Reding
2012-12-21 13:50 ` [PATCHv4 0/8] Support for Tegra 2D hardware Lucas Stach
2012-12-21 13:50 ` Lucas Stach
2012-12-21 13:57 ` Terje Bergström
2012-12-21 13:57 ` Terje Bergström
[not found] ` <50D46AE4.8020308-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 13:59 ` Lucas Stach
2012-12-21 13:59 ` Lucas Stach
2013-01-03 6:14 ` Terje Bergström
2013-01-03 6:14 ` Terje Bergström
2012-12-26 9:42 ` Mark Zhang
2012-12-26 9:42 ` Mark Zhang
2013-01-02 9:25 ` Terje Bergström
[not found] ` <50E3FD17.80402-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-03 2:36 ` Mark Zhang
2013-01-03 2:36 ` Mark Zhang
2012-12-28 9:14 ` Mark Zhang
[not found] ` <50DD6311.9000002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-02 9:42 ` Terje Bergström [this message]
2013-01-02 9:42 ` Terje Bergström
[not found] ` <50E40106.4020406-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-03 3:31 ` Mark Zhang
2013-01-03 3:31 ` Mark Zhang
[not found] ` <50E4FBAF.30700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-03 5:50 ` Terje Bergström
2013-01-03 5:50 ` Terje Bergström
[not found] ` <50E51C08.1020603-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-03 5:55 ` Mark Zhang
2013-01-03 5:55 ` Mark Zhang
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=50E40106.4020406@nvidia.com \
--to=tbergstrom-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=airlied-cv59FeDIM0c@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=nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@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.