dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2013-01-02  9:42 UTC|newest]

Thread overview: 35+ 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 ` [PATCHv4 1/8] gpu: host1x: Add host1x driver Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 2/8] gpu: host1x: Add syncpoint wait and interrupts Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 3/8] gpu: host1x: Add channel support Terje Bergstrom
     [not found]   ` <1356089964-5265-4-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
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  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
     [not found]           ` <50E3FE57.5070702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-02  9:43             ` Terje Bergström
2012-12-21 11:39 ` [PATCHv4 4/8] gpu: host1x: Add debug support 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
     [not found]     ` <1356089964-5265-6-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
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-28 21:21               ` Thierry Reding
2012-12-31  6:43                 ` Terje Bergström
     [not found]         ` <20121221143614.GA16167-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
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   ` [PATCHv4 8/8] gpu: host1x: Register DRM dummy device 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 14:09         ` Thierry Reding
2012-12-21 13:50   ` [PATCHv4 0/8] Support for Tegra 2D hardware Lucas Stach
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
2013-01-03  6:14     ` Terje Bergström
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
2012-12-21 11:39 ` [PATCHv4 7/8] drm: tegra: Add gr2d device Terje Bergstrom
2012-12-28  9:14 ` [PATCHv4 0/8] Support for Tegra 2D hardware Mark Zhang
     [not found]   ` <50DD6311.9000002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-02  9:42     ` Terje Bergström [this message]
     [not found]       ` <50E40106.4020406-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-03  3:31         ` Mark Zhang
     [not found]           ` <50E4FBAF.30700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).