linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Primoz Fiser <primoz.fiser@norik.com>
To: l.stach@pengutronix.de
Cc: akpm@linux-foundation.org, dri-devel@lists.freedesktop.org,
	dvyukov@google.com, etnaviv@lists.freedesktop.org,
	huyue2@yulong.com, kernel@pengutronix.de, linux-mm@kvack.org,
	m.szyprowski@samsung.com, mina86@mina86.com,
	patchwork-lst@pengutronix.de, thesven73@gmail.com,
	linux+etnaviv@armlinux.org.uk, s.riedmueller@phytec.de,
	y.bas@phytec.de, s.mueller-klieser@phytec.de
Subject: Re: [PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset if possible
Date: Mon,  3 May 2021 09:46:40 +0200	[thread overview]
Message-ID: <20210503074640.3412988-1-primoz.fiser@norik.com> (raw)
In-Reply-To: <20190529104312.27835-2-l.stach@pengutronix.de>

Hi,

what happened to these patches? In thread "[REGRESSION] drm/etnaviv: command
buffer outside valid memory window" [1] it was mentioned these got "shot
down" due to layering violations, but no official correspondence has been
found? Is is due to exporting symbols from mm/cma.c in [1/2] and why is this
an issue?

We are still affected by issue these patches tried to address and we are
interested in getting the solution into mainline.

Patches were integrated (small fix required due to renamed include file header)
and tested on latest master with PHYTEC's 2GiB phyCORE SoM and cma=256M kernel
cmdline parameter.

Without patches:

[    7.892954] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[    7.901286] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[    7.909809] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
[    7.915775] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[    7.924000] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[    7.930615] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[    7.936934] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[    7.948600] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 1
[   16.656092] etnaviv etnaviv: command buffer outside valid memory window
[   16.695777] etnaviv etnaviv: command buffer outside valid memory window
[   16.765654] etnaviv etnaviv: command buffer outside valid memory window
[   16.800111] etnaviv etnaviv: command buffer outside valid memory window

NOTE: See "command buffer outside valid memory window" errors when trying to
use GPU.

With patches:

[    7.708159] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[    7.716095] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[    7.724257] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
[    7.730205] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[    7.738407] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[    7.745039] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[    7.751365] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[    7.762876] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 1

NOTE: No errors, GPU fully functional!

In the end, it looks like we are not the only ones with the same issues as
patch "drm/etnaviv: optionally set gpu linear window to cma area"  that
addresses the same issue was submitted by Sven Van Asbroeck (see [2]). 
Unfortunately, his solution was also not accepted.

Please advise what would be the best solution implementation and how to
proceed in this case?

BR,
Primoz

[1] https://lists.freedesktop.org/archives/dri-devel/2019-June/223516.html

[2] https://lore.kernel.org/dri-devel/20190619183856.467-1-TheSven73@gmail.com/



  reply	other threads:[~2021-05-03  7:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 10:43 [PATCH 1/2] mm: cma: export functions to get CMA base and size Lucas Stach
2019-05-29 10:43 ` [PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset if possible Lucas Stach
2021-05-03  7:46   ` Primoz Fiser [this message]
2019-05-30  6:26 ` [PATCH 1/2] mm: cma: export functions to get CMA base and size Christoph Hellwig

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=20210503074640.3412988-1-primoz.fiser@norik.com \
    --to=primoz.fiser@norik.com \
    --cc=akpm@linux-foundation.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dvyukov@google.com \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=huyue2@yulong.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux+etnaviv@armlinux.org.uk \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mina86@mina86.com \
    --cc=patchwork-lst@pengutronix.de \
    --cc=s.mueller-klieser@phytec.de \
    --cc=s.riedmueller@phytec.de \
    --cc=thesven73@gmail.com \
    --cc=y.bas@phytec.de \
    /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