> Maybe you want to look at
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1190
>
> I updated this patch against mesa master, apparently the libdrm-etnaviv
> bits were folded into mesa now.
Thanks!
> >>stream->pipe = pipe;
> >>stream->reset_notify = reset_notify;
> >>strea
I guess so (but this doubt is why I've never done this change myself).
Reviewed-by: Wladimir J. van der Laan
> diff --git a/etnaviv/etnaviv_bo.c b/etnaviv/etnaviv_bo.c
> index 43ce6b4e..28ad3162 100644
> --- a/etnaviv/etnaviv_bo.c
> +++ b/etnaviv/etnaviv_bo.c
> @@ -44,14 +4
1 file changed, 3 insertions(+), 5 deletions(-)
Thanks for catching this.
Reviewed-by: Wladimir J. van der Laan
> diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
> index 7139c324..261777b0 100644
> --- a/etnaviv/etnaviv_cmd_stream.c
> +++ b/etnaviv/etnaviv
Pretty-print formats and modifiers in IN_FORMATS blob.
Signed-off-by: Wladimir J. van der Laan
---
tests/modeprint/modeprint.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 42c0a1b..ce84279 100644
This patch series adds support for printing the properties of all DRM mode
objects. This is subsequently used to parse the IN_FORMATS blob to be able to
print the available modifiers and their formats.
Wladimir J. van der Laan (2):
tests/modeprint: Print plane and other object properties
Make it possible to print plane properties, and the properties of other
DRM mode objects, if available.
Signed-off-by: Wladimir J. van der Laan
---
tests/modeprint/modeprint.c | 100 ++--
1 file changed, 96 insertions(+), 4 deletions(-)
diff --git a
his up by removing the usage of iommu_domain, which is the
> last piece linking etnaviv to the IOMMU subsystem.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Wladimir J. van der Laan
> ---
> drivers/gpu/drm/etnaviv/Kconfig| 2 -
> drivers/gpu/drm/etnaviv/etnaviv_
On Fri, Sep 15, 2017 at 07:04:38PM +0200, Lucas Stach wrote:
> And clean up the header file a bit.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Wladimir J. van der Laan
> ---
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 8
> drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 8 +
On Fri, Sep 15, 2017 at 07:04:37PM +0200, Lucas Stach wrote:
> This is a preparation to remove the etnaviv dependency on the IOMMU
> subsystem by importing the relevant parts of the iommu map/unamp
> functions into the driver.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Wladimir
On Fri, Sep 15, 2017 at 07:04:36PM +0200, Lucas Stach wrote:
> A function doing a single assignment is not really helping the
> code flow.
>
> Signed-off-by: Lucas Stach
agreed.
Reviewed-by: Wladimir J. van der Laan
> ---
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 16 +++
On Fri, Sep 15, 2017 at 07:04:33PM +0200, Lucas Stach wrote:
> They are not used in any way, so can go away.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Wladimir J. van der Laan
> ---
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 21 -
> drive
On Fri, Sep 15, 2017 at 07:04:35PM +0200, Lucas Stach wrote:
> It wasn't protecting anything, as the single word writes used to
> set up or tear down a translation are already inherently atomic,
> so the spinlock is pure overhead.
>
> Signed-off-by: Lucas Stach
Reviewed-by:
-off-by: Lucas Stach
Reviewed-by: Wladimir J. van der Laan
> ---
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 27 ---
> 1 file changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> b/drivers/gpu/drm/etnavi
On Fri, Sep 15, 2017 at 07:04:32PM +0200, Lucas Stach wrote:
> The handler has never been used, so it's really just dead code.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Wladimir J. van der Laan
> ---
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 9 -
> 1 fi
> Etnaviv isn't CMA based, so this is certainly not a valid fix. It
> probably doesn't crash anymore, as it isn't properly freeing the pages
> backing the GEM object.
>
> I've seen this crash in the early days of etnaviv a few times, but it
> hasn't happened to me in a long time.
I don't recogni
A relocation pointing to the last four bytes of a buffer can
legitimately happen in the case of small vertex buffers.
Signed-off-by: Wladimir J. van der Laan
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
On Wed, Apr 05, 2017 at 09:50:23AM -0300, Fabio Estevam wrote:
> On Sat, Apr 1, 2017 at 6:40 PM, Fabio Estevam wrote:
> > Hi Wladimir,
> >
> > On Fri, Mar 31, 2017 at 2:36 AM, Wladimir J. van der Laan
> > wrote:
> >
> >> - Went as far back as kernel
On Sat, Apr 01, 2017 at 06:40:52PM -0300, Fabio Estevam wrote:
> Hi Wladimir,
>
> On Fri, Mar 31, 2017 at 2:36 AM, Wladimir J. van der Laan
> wrote:
>
> > - Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863,
> > "ARM:
> > dts:
Hello Philipp,
> Looking at the hardware user's guide [1] chapter 9 (VGA and DVI out), I
> notice that the TFP410PA bridge seems to be connected to the DISP2_DAT
> data lines, but uses the DISP1_H/V sync signals (which I can't believe
> is right), according to figure 9-1. But the device tree pin
>
Hello,
I can't get the DVI output to work on a i.MX51 EVP board (babbage). There
seems to be no signal at all. The board is running the mainline kernel
4.11.0-rc4 as of a
day ago (89970a0).
- The connector and cable works. u-boot (v2016.07-rc2) shows a penguin at boot.
However while the Linux
Hello,
With the Etnaviv driver we're running into an issue: The GPU can only render
*to*
BGRA formats. It can however render *from* BGRA as well as RGBA textures.
I know that the OpenGL ES standard allows drivers to choose what order is most
appropriate when being asked for "GL_RGBA" textures. S
get the result.
- tex_amode needs to be set to 1.
Add a new bit to the compiler specs and generate these instructions
as necessary.
Signed-Off-By: Wladimir J. van der Laan
---
src/gallium/drivers/etnaviv/etnaviv_compiler.c | 37 +-
src/gallium/drivers/etnaviv
Reviewed-By: Wladimir J. van der Laan
I do wonder whether we'll need the split formats in practice -
e.g. the GC3000 on the i.MX6qp, for which I suppose this is being done because
of tiled buffers support in the PRE, has the "single buffer" feature
which allows rendering to a sin
uge impact on shader performance (sped up
memory read performance by 7.5x and write performance by 1.5x) on an
affected GPU.
Signed-off-by: Wladimir J. van der Laan
---
Changes since v1:
- Add Signed-off-by line
- Move functionality to function
- Remove #define
- Collapse comments
drivers/gp
).
Signed-off-by: Wladimir J. van der Laan
---
In comparison to v1 this adds a signed-off-by line and adds MRT
states.
drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
b/drivers/gpu/drm/etnaviv
- Add PS.INST_ADDR and VS.INST_ADDR: GC3000 loads shader code from these
addresses if ICACHE
is enabled.
- Add new NFE vertex stream addresses.
---
drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
b/
Set up the PULSE_EATER register (0x0010C) in etnaviv_gpu_hw_init. This
ports three mostly undocumented model/revision-specific register
overrides from the Vivante kernel driver.
This is relevant as at least the "disable internal DFS" for revisions >
0x5420 has shown to have a huge impact on shader
> The current etnaviv code gets around this stop->irq->start dance by
> spacing out the command streams, which seems to be enough to get around
> the FE MMU flush failure. This may not work correctly at the end of the
> address range. I'll take a look at this.
In my case it seems not a command bu
> So the MMU fault is somehow specific to what I'm doing. Interesting.
I think I found the issue: the MMU "flush and sync" is not good enough in some
cases.
What the Vivante kernel driver does, for MMUv2, after mapping some kinds of
buffer objects (apparently those tagged INDEX and VERTEX, this i
> <3>[ 549.814025] etnaviv-gpu 13.gpu: MMU fault status 0x0002 <-
> happens almost immediately
> <3>[ 549.819960] etnaviv-gpu 13.gpu: MMU 0 fault addr 0xe8783040
> <3>[ 549.825889] etnaviv-gpu 13.gpu: MMU 1 fault addr 0x
> <3>[ 549.831817] etnaviv-gpu 13.gpu: MMU 2
I'm having an issue where a long-running test eventually runs into a MMU
fault. What this test does is basically:
- while [ 1 ]; do start a program that:
- Allocate bo A, B and C, D
- Map bo C, update it
- Loop
- Map bo A B and C, update them
- Build command buffer
On Fri, Dec 09, 2016 at 12:21:29PM +0100, Christian Gmeiner wrote:
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1379,6 +1379,9 @@ static void etnaviv_process_readbacks(struct
> etnaviv_gpu *gpu,
> const u32 val = gpu_read(gpu, read
Exposing rb swapped (or other swizzled) formats for rendering would
involve swizzing in the pixel shader. This is not the case at the
moment, so reject requests for creating such surfaces.
(GPUs that need an extra resolve step anyway due to multiple pixel
pipes, such as gc2000, might also do this
command is not allowed currently by the DRM driver because it
was not known before. This patch enables parsing it in command
streams and allows using it by userspace drivers.
Signed-off-by: Wladimir J. van der Laan
---
drivers/gpu/drm/etnaviv/cmdstream.xml.h | 60
Hello,
After running kmscube (or another KMS executable) on a i.MX6 QuadPlus (etnaviv,
GC3000) a few times on I get the below crash in the drm kernel driver.
This is on a device with LVDS panel. It is always reproducible, although the
number of invocations needed differs.
The only way to get rend
35 matches
Mail list logo
