Re: [PATCH libdrm] etnaviv: Use hash table to track BO indexes
> 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; > >>stream->reset_notify_priv = priv; > >> + stream->seqno = ++dev->stream_cnt; > > > > Do we have to catch integer overflow here? > > It's very unlikely for there to have been 2^32 streams, but if it happens > > it might be good to at least > > warn. > > I don't think so. > > If you allocated (2^(machine word size))-1 streams, you would exhaust > your memory long before that. And this can actually roll over, since if > you were to allocate streams one after the other and then free them, > their numbers would just increment without colliding. > > I guess what could happen here would be something like, you allocate > stream #0 , then allocate/free (2^(machine word size)) - 2 streams and > then allocating the (2^(machine word size)) - 1th stream would end up > allocating new stream with the same stream count (?). This is the scenario that I was imagining, in which two separate streams could collide with the same seq no (resulting in weird glitches in bo tracking), but yes, it seems very unlikely. Kind regards, Wladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] etnaviv: Use hash table to track BO indexes
On Tue, Jun 04, 2019 at 01:39:29AM +0200, Marek Vasut wrote:
> Use hash table instead of ad-hoc arrays.
>
> Signed-off-by: Marek Vasut
> Cc: Christian Gmeiner
> Cc: Lucas Stach
> ---
> etnaviv/etnaviv_bo.c | 6 +++---
> etnaviv/etnaviv_cmd_stream.c | 31 ++-
> etnaviv/etnaviv_priv.h | 17 ++---
> 3 files changed, 35 insertions(+), 19 deletions(-)
I do not know how to quantify the performance difference here, is using a hash
table faster than an ad-hoc array for the typically small sized arrays here?
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 +44,14 @@ drm_private void bo_del(struct etna_bo *bo)
> if (bo->map)
> drm_munmap(bo->map, bo->size);
>
> - if (bo->name)
> - drmHashDelete(bo->dev->name_table, bo->name);
> -
> if (bo->handle) {
> struct drm_gem_close req = {
> .handle = bo->handle,
> };
>
> + if (bo->name)
> + drmHashDelete(bo->dev->name_table, bo->name);
> +
> drmHashDelete(bo->dev->handle_table, bo->handle);
> drmIoctl(bo->dev->fd, DRM_IOCTL_GEM_CLOSE, );
> }
> diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
> index 261777b0..f550b2ff 100644
> --- a/etnaviv/etnaviv_cmd_stream.c
> +++ b/etnaviv/etnaviv_cmd_stream.c
> @@ -61,6 +61,7 @@ drm_public struct etna_cmd_stream
> *etna_cmd_stream_new(struct etna_pipe *pipe,
> void *priv)
> {
> struct etna_cmd_stream_priv *stream = NULL;
> + struct etna_device *dev = pipe->gpu->dev;
>
> if (size == 0) {
> ERROR_MSG("invalid size of 0");
> @@ -86,6 +87,7 @@ drm_public struct etna_cmd_stream
> *etna_cmd_stream_new(struct etna_pipe *pipe,
> stream->pipe = pipe;
> stream->reset_notify = reset_notify;
> stream->reset_notify_priv = priv;
> + stream->seqno = ++dev->stream_cnt;
Do we have to catch integer overflow here?
It's very unlikely for there to have been 2^32 streams, but if it happens it
might be good to at least
warn.
> return >base;
>
> @@ -150,18 +152,24 @@ static uint32_t bo2idx(struct etna_cmd_stream *stream,
> struct etna_bo *bo,
>
> pthread_mutex_lock(_lock);
>
> - if (bo->current_stream == stream) {
> + if (bo->current_stream_seqno == priv->seqno) {
> idx = bo->idx;
> } else {
> - /* slow-path: */
> - for (idx = 0; idx < priv->nr_bos; idx++)
> - if (priv->bos[idx] == bo)
> - break;
> - if (idx == priv->nr_bos) {
> - /* not found */
> + void *val;
> +
> + if (!priv->bo_table)
> + priv->bo_table = drmHashCreate();
> +
> + if (!drmHashLookup(priv->bo_table, bo->handle, )) {
> + /* found */
> + idx = (uint32_t)(uintptr_t)val;
> + } else {
> idx = append_bo(stream, bo);
> + val = (void *)(uintptr_t)idx;
> + drmHashInsert(priv->bo_table, bo->handle, val);
> }
> - bo->current_stream = stream;
> +
> + bo->current_stream_seqno = priv->seqno;
> bo->idx = idx;
> }
> pthread_mutex_unlock(_lock);
> @@ -213,10 +221,15 @@ static void flush(struct etna_cmd_stream *stream, int
> in_fence_fd,
> for (uint32_t i = 0; i < priv->nr_bos; i++) {
> struct etna_bo *bo = priv->bos[i];
>
> - bo->current_stream = NULL;
> + bo->current_stream_seqno = 0;
> etna_bo_del(bo);
> }
>
> + if (priv->bo_table) {
> + drmHashDestroy(priv->bo_table);
> + priv->bo_table = NULL;
> + }
> +
> if (out_fence_fd)
> *out_fence_fd = req.fence_fd;
> }
> diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
> index eef7f49c..bc82324e 100644
> --- a/etnaviv/etnaviv_priv.h
> +++ b/etnaviv/etnaviv_priv.h
> @@ -76,6 +76,8 @@ struct etna_device {
> struct etna_bo_cache bo_cache;
>
> int closefd;/* call close(fd) upon destruction */
> +
>
Re: [PATCH libdrm] etnaviv: Fix double-free in etna_bo_cache_free()
On Sun, Jun 02, 2019 at 01:36:27AM +0200, Marek Vasut wrote:
> The following situation can happen in a multithreaded OpenGL application.
> A BO is submitted from etna_cmd_stream #1 with flags set for read.
> A BO is submitted from etna_cmd_stream #2 with flags set for write.
> This triggers a flush on stream #1 and clears the BO's current_stream
> pointer. If at this point, stream #2 attempts to queue BO again, which
> does happen, the BO will be added to the submit list twice. The Linux
> kernel driver correctly detects this and warns about it with "BO at
> index %u already on submit list" kernel message.
>
> However, when cleaning the BO cache in etna_bo_cache_free(), the BO
> which was submitted twice will also be free()d twice, this triggering
> a glibc double free detector.
>
> The fix is easy, even if the BO does not have current_stream set,
> iterate over current streams' list of BOs before adding the BO to it
> and verify that the BO is not yet there.
>
> Signed-off-by: Marek Vasut
> Cc: Christian Gmeiner
> Cc: Lucas Stach
> ---
> etnaviv/etnaviv_cmd_stream.c | 8 +++-
> 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_cmd_stream.c
> @@ -150,11 +150,7 @@ static uint32_t bo2idx(struct etna_cmd_stream *stream,
> struct etna_bo *bo,
>
> pthread_mutex_lock(_lock);
>
> - if (!bo->current_stream) {
> - idx = append_bo(stream, bo);
> - bo->current_stream = stream;
> - bo->idx = idx;
> - } else if (bo->current_stream == stream) {
> + if (bo->current_stream == stream) {
> idx = bo->idx;
> } else {
> /* slow-path: */
> @@ -165,6 +161,8 @@ static uint32_t bo2idx(struct etna_cmd_stream *stream,
> struct etna_bo *bo,
> /* not found */
> idx = append_bo(stream, bo);
> }
> + bo->current_stream = stream;
> + bo->idx = idx;
> }
> pthread_mutex_unlock(_lock);
>
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] tests/modeprint: Print details for IN_FORMATS blob
Pretty-print formats and modifiers in IN_FORMATS blob.
Signed-off-by: Wladimir J. van der Laan <laa...@gmail.com>
---
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
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -93,6 +93,28 @@ static int printMode(struct drm_mode_modeinfo *mode)
return 0;
}
+static int printBlob(const char *name, void *data, uint32_t length)
+{
+ if (!strcmp(name, "IN_FORMATS")) {
+ struct drm_format_modifier_blob *m = data;
+ uint32_t *fmts = (uint32_t *)(((char *)data) +
m->formats_offset);
+ struct drm_format_modifier *mod = (struct drm_format_modifier
*)(((char *)data) + m->modifiers_offset);
+ int i,j,k;
+ printf("\tmodifiers:\n");
+ for (j = 0; j < (int)m->count_modifiers; j++) {
+ printf("\t\t0x%016" PRIx64, mod[j].modifier);
+ for (i = 0; i < 64 && (i + mod[j].offset) <
(int)m->count_formats; i++) {
+ if (mod[j].formats & (1<<i)) {
+ k = i + mod[j].offset;
+ printf(" %c%c%c%c", fmts[k] >> 24,
fmts[k] >> 16, fmts[k] >> 8, fmts[k] >> 0);
+ }
+ }
+ printf("\n");
+ }
+ }
+ return 0;
+}
+
static int printProperty(int fd, drmModePropertyPtr props, uint64_t value)
{
const char *name = NULL;
@@ -120,6 +142,7 @@ static int printProperty(int fd, drmModePropertyPtr props,
uint64_t value)
blob = drmModeGetPropertyBlob(fd, value);
if (blob) {
printf("blob is %d length, %08X\n", blob->length,
*(uint32_t *)blob->data);
+ printBlob(props->name, blob->data, blob->length);
drmModeFreePropertyBlob(blob);
} else {
printf("error getting blob %" PRIu64 "\n", value);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 0/2] Print plane modifiers in modeprint
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 tests/modeprint: Print details for IN_FORMATS blob tests/modeprint/modeprint.c | 122 ++-- 1 file changed, 118 insertions(+), 4 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/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 <laa...@gmail.com>
---
tests/modeprint/modeprint.c | 100 ++--
1 file changed, 96 insertions(+), 4 deletions(-)
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 0d85410..42c0a1b 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -52,6 +52,7 @@ int full_modes;
int encoders;
int crtcs;
int fbs;
+int planes;
char *module_name;
static const char* getConnectionText(drmModeConnection conn)
@@ -92,7 +93,7 @@ static int printMode(struct drm_mode_modeinfo *mode)
return 0;
}
-static int printProperty(int fd, drmModeResPtr res, drmModePropertyPtr props,
uint64_t value)
+static int printProperty(int fd, drmModePropertyPtr props, uint64_t value)
{
const char *name = NULL;
int j;
@@ -141,6 +142,25 @@ static int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, ui
return 0;
}
+static int printObjectProps(int fd, uint32_t object_id, uint32_t object_type)
+{
+ uint32_t i;
+
+ drmModeObjectPropertiesPtr props = drmModeObjectGetProperties(fd,
object_id, object_type);
+ if (props) {
+ for (i = 0; i < props->count_props; i++) {
+ drmModePropertyPtr prop = drmModeGetProperty(fd,
props->props[i]);
+ if (prop) {
+ printProperty(fd, prop, props->prop_values[i]);
+ drmModeFreeProperty(prop);
+ }
+ }
+ drmModeFreeObjectProperties(props);
+ }
+
+ return 0;
+}
+
static const char * const output_names[] = { "None",
"VGA",
"DVI-I",
@@ -204,7 +224,7 @@ static int printConnector(int fd, drmModeResPtr res,
drmModeConnectorPtr connect
for (i = 0; i < connector->count_props; i++) {
props = drmModeGetProperty(fd, connector->props[i]);
if (props) {
- printProperty(fd, res, props,
connector->prop_values[i]);
+ printProperty(fd, props,
connector->prop_values[i]);
drmModeFreeProperty(props);
}
}
@@ -221,6 +241,11 @@ static int printEncoder(int fd, drmModeResPtr res,
drmModeEncoderPtr encoder, ui
printf("\ttype :%d\n", encoder->encoder_type);
printf("\tpossible_crtcs :0x%x\n", encoder->possible_crtcs);
printf("\tpossible_clones :0x%x\n", encoder->possible_clones);
+
+ if (full_props) {
+ printObjectProps(fd, encoder->crtc_id, DRM_MODE_OBJECT_ENCODER);
+ }
+
return 0;
}
@@ -235,6 +260,10 @@ static int printCrtc(int fd, drmModeResPtr res,
drmModeCrtcPtr crtc, uint32_t id
printf("\tmode : %p\n", >mode);
printf("\tgamma size : %d\n", crtc->gamma_size);
+ if (full_props) {
+ printObjectProps(fd, crtc->crtc_id, DRM_MODE_OBJECT_CRTC);
+ }
+
return 0;
}
@@ -249,16 +278,50 @@ static int printFrameBuffer(int fd, drmModeResPtr res,
drmModeFBPtr fb)
printf("\tdepth : %i\n", fb->depth);
printf("\tbuffer_id : %i\n", fb->handle);
+ if (full_props) {
+ printObjectProps(fd, fb->fb_id, DRM_MODE_OBJECT_FB);
+ }
+
+ return 0;
+}
+
+static int printPlane(int fd, drmModePlanePtr plane)
+{
+ uint32_t i;
+
+ printf("Plane\n");
+ printf("\tcount_formats : %i\n", plane->count_formats);
+ if (plane->count_formats) {
+ printf("\tformats:");
+ for (i = 0; i < plane->count_formats; i++)
+ printf(" %c%c%c%c", plane->formats[i] >> 24,
plane->formats[i] >> 16, plane->formats[i] >> 8, plane->formats[i] >> 0);
+ printf("\n");
+ }
+ printf("\tplane_id : %i\n", plane->plane_id);
+ printf("\tcrtc_id: %i\n", plane->crtc_id);
+ printf("\tfb_id : %i\n", plane->fb_id);;
+ printf("\tcrtc_x : %i\n", plane->crtc_x);
+ printf("\tcrtc_y : %i\n", plane->crtc_y);
+ printf("\tx : %i\n", plane->x);
+ printf("\ty : %i\n", plane->y);
+ printf("\tpossible_crtcs : 0x%x\n", plane->possible_crtcs);
+ printf("\tgamma_size : %i\n", plane->ga
Re: [PATCH 8/8] etnaviv: remove IOMMU dependency
On Fri, Sep 15, 2017 at 07:04:39PM +0200, Lucas Stach wrote: > Using the IOMMU API to manage the internal GPU MMU has been an > historical accident and it keeps getting in the way, as well as > entangling the driver with the inner workings of the IOMMU > subsystem. > > Clean this up by removing the usage of iommu_domain, which is the > last piece linking etnaviv to the IOMMU subsystem. > > Signed-off-by: Lucas Stach <l.st...@pengutronix.de> Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com> > --- > drivers/gpu/drm/etnaviv/Kconfig| 2 - > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 71 > +++--- > drivers/gpu/drm/etnaviv/etnaviv_iommu.h| 6 ++- > drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 55 +++ > drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 38 +++- > drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 20 ++--- > 7 files changed, 93 insertions(+), 100 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] etnaviv: mmu: mark local functions static
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 <l.st...@pengutronix.de> Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com> > --- > drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 8 > drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 8 +--- > 2 files changed, 5 insertions(+), 11 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] etnaviv: mmu: stop using iommu map/unmap functions
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 <l.st...@pengutronix.de> Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] etnaviv: iommuv1: fold pgtable_write into callers
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 <l.st...@pengutronix.de>
agreed.
Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> index 78a7c0f3064a..43a0508bdbd7 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> @@ -49,15 +49,6 @@ static struct etnaviv_iommu_domain
> *to_etnaviv_domain(struct iommu_domain *domai
> return container_of(domain, struct etnaviv_iommu_domain, domain);
> }
>
> -static void pgtable_write(struct etnaviv_iommu_domain_pgtable *pgtable,
> - unsigned long iova, phys_addr_t paddr)
> -{
> - /* calcuate index into page table */
> - unsigned int index = (iova - GPU_MEM_START) / SZ_4K;
> -
> - pgtable->pgtable[index] = paddr;
> -}
> -
> static int __etnaviv_iommu_init(struct etnaviv_iommu_domain *etnaviv_domain)
> {
> u32 *p;
> @@ -111,11 +102,12 @@ static int etnaviv_iommuv1_map(struct iommu_domain
> *domain, unsigned long iova,
> phys_addr_t paddr, size_t size, int prot)
> {
> struct etnaviv_iommu_domain *etnaviv_domain = to_etnaviv_domain(domain);
> + unsigned int index = (iova - GPU_MEM_START) / SZ_4K;
>
> if (size != SZ_4K)
> return -EINVAL;
>
> - pgtable_write(_domain->pgtable, iova, paddr);
> + etnaviv_domain->pgtable.pgtable[index] = paddr;
>
> return 0;
> }
> @@ -124,12 +116,12 @@ static size_t etnaviv_iommuv1_unmap(struct iommu_domain
> *domain,
> unsigned long iova, size_t size)
> {
> struct etnaviv_iommu_domain *etnaviv_domain = to_etnaviv_domain(domain);
> + unsigned int index = (iova - GPU_MEM_START) / SZ_4K;
>
> if (size != SZ_4K)
> return -EINVAL;
>
> - pgtable_write(_domain->pgtable, iova,
> - etnaviv_domain->bad_page_dma);
> + etnaviv_domain->pgtable.pgtable[index] = etnaviv_domain->bad_page_dma;
>
> return SZ_4K;
> }
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] etnaviv: remove iova_to_phys iommu ops
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 <l.st...@pengutronix.de>
Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 21 -
> drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 14 --
> 2 files changed, 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> index 7a7c97f599d7..f804c0aaa7a2 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> @@ -66,18 +66,6 @@ static void pgtable_free(struct
> etnaviv_iommu_domain_pgtable *pgtable,
> dma_free_coherent(NULL, size, pgtable->pgtable, pgtable->paddr);
> }
>
> -static u32 pgtable_read(struct etnaviv_iommu_domain_pgtable *pgtable,
> -unsigned long iova)
> -{
> - /* calcuate index into page table */
> - unsigned int index = (iova - GPU_MEM_START) / SZ_4K;
> - phys_addr_t paddr;
> -
> - paddr = pgtable->pgtable[index];
> -
> - return paddr;
> -}
> -
> static void pgtable_write(struct etnaviv_iommu_domain_pgtable *pgtable,
> unsigned long iova, phys_addr_t paddr)
> {
> @@ -164,14 +152,6 @@ static size_t etnaviv_iommuv1_unmap(struct iommu_domain
> *domain,
> return SZ_4K;
> }
>
> -static phys_addr_t etnaviv_iommu_iova_to_phys(struct iommu_domain *domain,
> - dma_addr_t iova)
> -{
> - struct etnaviv_iommu_domain *etnaviv_domain = to_etnaviv_domain(domain);
> -
> - return pgtable_read(_domain->pgtable, iova);
> -}
> -
> static size_t etnaviv_iommuv1_dump_size(struct iommu_domain *domain)
> {
> return PT_SIZE;
> @@ -189,7 +169,6 @@ static const struct etnaviv_iommu_ops etnaviv_iommu_ops =
> {
> .domain_free = etnaviv_domain_free,
> .map = etnaviv_iommuv1_map,
> .unmap = etnaviv_iommuv1_unmap,
> - .iova_to_phys = etnaviv_iommu_iova_to_phys,
> .pgsize_bitmap = SZ_4K,
> },
> .dump_size = etnaviv_iommuv1_dump_size,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> index cbe447ac5974..d794e8c0dd7e 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> @@ -97,19 +97,6 @@ static size_t etnaviv_iommuv2_unmap(struct iommu_domain
> *domain,
> return SZ_4K;
> }
>
> -static phys_addr_t etnaviv_iommuv2_iova_to_phys(struct iommu_domain *domain,
> - dma_addr_t iova)
> -{
> - struct etnaviv_iommuv2_domain *etnaviv_domain =
> - to_etnaviv_domain(domain);
> - int mtlb_entry, stlb_entry;
> -
> - mtlb_entry = (iova & MMUv2_MTLB_MASK) >> MMUv2_MTLB_SHIFT;
> - stlb_entry = (iova & MMUv2_STLB_MASK) >> MMUv2_STLB_SHIFT;
> -
> - return etnaviv_domain->stlb_cpu[mtlb_entry][stlb_entry] & ~(SZ_4K - 1);
> -}
> -
> static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain
> *etnaviv_domain)
> {
> u32 *p;
> @@ -235,7 +222,6 @@ static const struct etnaviv_iommu_ops etnaviv_iommu_ops =
> {
> .domain_free = etnaviv_iommuv2_domain_free,
> .map = etnaviv_iommuv2_map,
> .unmap = etnaviv_iommuv2_unmap,
> - .iova_to_phys = etnaviv_iommuv2_iova_to_phys,
> .pgsize_bitmap = SZ_4K,
> },
> .dump_size = etnaviv_iommuv2_dump_size,
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] etnaviv: iommuv1: remove map_lock
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 <l.st...@pengutronix.de>
Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> index aaa8c4136f53..78a7c0f3064a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> @@ -42,7 +42,6 @@ struct etnaviv_iommu_domain {
> void *bad_page_cpu;
> dma_addr_t bad_page_dma;
> struct etnaviv_iommu_domain_pgtable pgtable;
> - spinlock_t map_lock;
> };
>
> static struct etnaviv_iommu_domain *to_etnaviv_domain(struct iommu_domain
> *domain)
> @@ -90,8 +89,6 @@ static int __etnaviv_iommu_init(struct etnaviv_iommu_domain
> *etnaviv_domain)
> etnaviv_domain->pgtable.pgtable[i] =
> etnaviv_domain->bad_page_dma;
>
> - spin_lock_init(_domain->map_lock);
> -
> return 0;
> }
>
> @@ -118,9 +115,7 @@ static int etnaviv_iommuv1_map(struct iommu_domain
> *domain, unsigned long iova,
> if (size != SZ_4K)
> return -EINVAL;
>
> - spin_lock(_domain->map_lock);
> pgtable_write(_domain->pgtable, iova, paddr);
> - spin_unlock(_domain->map_lock);
>
> return 0;
> }
> @@ -133,10 +128,8 @@ static size_t etnaviv_iommuv1_unmap(struct iommu_domain
> *domain,
> if (size != SZ_4K)
> return -EINVAL;
>
> - spin_lock(_domain->map_lock);
> pgtable_write(_domain->pgtable, iova,
> etnaviv_domain->bad_page_dma);
> - spin_unlock(_domain->map_lock);
>
> return SZ_4K;
> }
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] etnaviv: iommuv1: fold pagetable alloc and free into caller
On Fri, Sep 15, 2017 at 07:04:34PM +0200, Lucas Stach wrote:
> Those functions are simple enough to fold them into the calling
> function. This also fixes a correctness issue, as the alloc/free
> functions didn't specifiy the device the memory was allocated for.
>
> Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com>
> ---
> 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/etnaviv/etnaviv_iommu.c
> index f804c0aaa7a2..aaa8c4136f53 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> @@ -50,22 +50,6 @@ static struct etnaviv_iommu_domain
> *to_etnaviv_domain(struct iommu_domain *domai
> return container_of(domain, struct etnaviv_iommu_domain, domain);
> }
>
> -static int pgtable_alloc(struct etnaviv_iommu_domain_pgtable *pgtable,
> - size_t size)
> -{
> - pgtable->pgtable = dma_alloc_coherent(NULL, size, >paddr,
> GFP_KERNEL);
> - if (!pgtable->pgtable)
> - return -ENOMEM;
> -
> - return 0;
> -}
> -
> -static void pgtable_free(struct etnaviv_iommu_domain_pgtable *pgtable,
> - size_t size)
> -{
> - dma_free_coherent(NULL, size, pgtable->pgtable, pgtable->paddr);
> -}
> -
> static void pgtable_write(struct etnaviv_iommu_domain_pgtable *pgtable,
> unsigned long iova, phys_addr_t paddr)
> {
> @@ -91,8 +75,11 @@ static int __etnaviv_iommu_init(struct
> etnaviv_iommu_domain *etnaviv_domain)
> for (i = 0; i < SZ_4K / 4; i++)
> *p++ = 0xdead55aa;
>
> - ret = pgtable_alloc(_domain->pgtable, PT_SIZE);
> - if (ret < 0) {
> + etnaviv_domain->pgtable.pgtable =
> + dma_alloc_coherent(etnaviv_domain->dev, PT_SIZE,
> +_domain->pgtable.paddr,
> +GFP_KERNEL);
> + if (!etnaviv_domain->pgtable.pgtable) {
> dma_free_coherent(etnaviv_domain->dev, SZ_4K,
> etnaviv_domain->bad_page_cpu,
> etnaviv_domain->bad_page_dma);
> @@ -112,7 +99,9 @@ static void etnaviv_domain_free(struct iommu_domain
> *domain)
> {
> struct etnaviv_iommu_domain *etnaviv_domain = to_etnaviv_domain(domain);
>
> - pgtable_free(_domain->pgtable, PT_SIZE);
> + dma_free_coherent(etnaviv_domain->dev, PT_SIZE,
> + etnaviv_domain->pgtable.pgtable,
> + etnaviv_domain->pgtable.paddr);
>
> dma_free_coherent(etnaviv_domain->dev, SZ_4K,
> etnaviv_domain->bad_page_cpu,
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] etnaviv: remove iommu fault handler
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 <l.st...@pengutronix.de>
Reviewed-by: Wladimir J. van der Laan <laa...@gmail.com>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index f103e787de94..f3ed07db9b2d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -22,13 +22,6 @@
> #include "etnaviv_iommu.h"
> #include "etnaviv_mmu.h"
>
> -static int etnaviv_fault_handler(struct iommu_domain *iommu, struct device
> *dev,
> - unsigned long iova, int flags, void *arg)
> -{
> - DBG("*** fault: iova=%08lx, flags=%d", iova, flags);
> - return 0;
> -}
> -
> int etnaviv_iommu_map(struct etnaviv_iommu *iommu, u32 iova,
> struct sg_table *sgt, unsigned len, int prot)
> {
> @@ -307,8 +300,6 @@ struct etnaviv_iommu *etnaviv_iommu_new(struct
> etnaviv_gpu *gpu)
> mmu->domain->geometry.aperture_end -
> mmu->domain->geometry.aperture_start + 1);
>
> - iommu_set_fault_handler(mmu->domain, etnaviv_fault_handler, gpu->dev);
> -
> return mmu;
> }
>
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Etnaviv crashes on glmark2
> 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 recognize this either, I haven't seen a kernel memory managment error while running glmark2 (or anything w/ etnaviv) for a long time. Strange. Regards, Wladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: Fix off-by-one error in reloc checking
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 <laa...@gmail.com>
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index de80ee1..21be4dc 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -270,8 +270,8 @@ static int submit_reloc(struct etnaviv_gem_submit *submit,
void *stream,
if (ret)
return ret;
- if (r->reloc_offset >= bo->obj->base.size - sizeof(*ptr)) {
- DRM_ERROR("relocation %u outside object", i);
+ if (r->reloc_offset > bo->obj->base.size - sizeof(*ptr)) {
+ DRM_ERROR("relocation %u outside object\n", i);
return -EINVAL;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DVI output on i.MX51 EVP board not working?
On Wed, Apr 05, 2017 at 09:50:23AM -0300, Fabio Estevam wrote: > On Sat, Apr 1, 2017 at 6:40 PM, Fabio Estevam <feste...@gmail.com> wrote: > > Hi Wladimir, > > > > On Fri, Mar 31, 2017 at 2:36 AM, Wladimir J. van der Laan > > <laa...@gmail.com> wrote: > > > >> - Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863, > >> "ARM: > >> dts: imx51-babbage: Make DVI and WVGA panel functional"). No difference. > >> So nothing to > >> bisect, unfortunately. > > > > It was a long time I worked on this commit and it worked well for me > > on an old DVI monitor. > > > > I will try to locate such monitor in the office next week and try it again. > > Finally had a chance to test it and I can see both U-Boot logo and > kernel penguin correctly on my monitor. Ok, thanks for testing. To be clear: was this result with v3.x, or with mainline? Regards, Wladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DVI output on i.MX51 EVP board not working?
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 > <laa...@gmail.com> wrote: > > > - Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863, > > "ARM: > > dts: imx51-babbage: Make DVI and WVGA panel functional"). No difference. > > So nothing to > > bisect, unfortunately. > > It was a long time I worked on this commit and it worked well for me > on an old DVI monitor. An extra data point: I tried with an older monitor (max 1280x1024) w/ DVI to DVI cable, exactly the same behavior: u-boot shows output but "no signal" when kernel boots. I was not able to go all the way back though, and only tested this with mainline. > I will try to locate such monitor in the office next week and try it again. Thanks! Regards, Wladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DVI output on i.MX51 EVP board not working?
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 > configuration configures the DISP1_DAT data lines with pinctrl_ipu_disp1 > instead. This pin configuration was moved there from imx51.dtsi, so I > think it was just never adapted for this boards' quirks. Interesting, thanks a lot for pointing that out. The figure 1-3 on page 6 shows both Disp-1 and Disp-2 going to the DVI-I connector, however the output of Disp-2 goes through the DAC so I suppose that's for the VGA pins. The figure 9-1 seems to be in conflict with that. DISP1_DAT isn't used at all there, but DISP2_DAT (albeit different pin ranges) go to both the ADV7123 and TFP410PA. > It might also be useful to find out which GPIOs are connected to the > TFP410 power down and reset lines. Yes, indeed. Luckily it works in u-boot so that's a reference. Regards, Wladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
DVI output on i.MX51 EVP board not working?
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 kernel boots, the signal goes away: monitor (a fairly
old Dell 24" panel, max resolution 1600x1200, works fine with Linux/DRM with
other
hardware) goes to sleep mode.
- Monitor is connected through HDMI<->DVI cable, could try another monitor if
that's potentially the issue (Could it be EDID related? I'd guess not as the
timings
are hardcoded in the device tree).
- Haven't changed anything in the dtb with regard to port config or resolution
or timings. The default ones in imx51-babbage.dts should theoretically just
work. I checked and these are the same as in u-boot:
timing0: dvi {
clock-frequency = <6500>;
hactive = <1024>;
vactive = <768>;
hback-porch = <220>;
hfront-porch = <40>;
vback-porch = <21>;
vfront-porch = <7>;
hsync-len = <60>;
vsync-len = <10>;
};
- Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863, "ARM:
dts: imx51-babbage: Make DVI and WVGA panel functional"). No difference. So
nothing to
bisect, unfortunately.
- In dmesg this is all the output I get:
[0.801700] imx-ipuv3 4000.ipu: no port@0 node in /soc/ipu@4000, not
using CSI0
[0.809826] imx-ipuv3 4000.ipu: no port@1 node in /soc/ipu@4000, not
using CSI1
[0.818600] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[0.825230] [drm] No driver support for vblank timestamp query.
[0.831481] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops
ipu_crtc_ops)
[0.839132] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops
ipu_crtc_ops)
[0.846617] imx-drm display-subsystem: bound display@di0 (ops imx_pd_ops)
[0.986410] Console: switching to colour frame buffer device 128x48
[1.032306] imx-drm display-subsystem: fb0: frame buffer device
[1.039362] [drm] Initialized imxdrm 1.0.0 20120507 for display-subsystem on
minor 0
[1.047276] imx-ipuv3 4000.ipu: IPUv3EX probed
As far as I know this is nothing unexpected. CSI0 and CSI1 are not connected
but DI0 should be the
DVI port, which does get initialized. The size of the framebuffer device seems
to indicate the resolution
is set correctly (assuming 16x8 characters).
There was also a "timeout waiting for vsync" error,
[0.917254] WARNING: CPU: 0 PID: 1 at
drivers/gpu/drm/drm_atomic_helper.c:1122
drm_atomic_helper_wait_for_vblanks.part.0+0x264/0x274
[0.917259] [CRTC:26] vblank wait timed out
which was fixed after applying Philipp Zabel's "drm/imx: don't wait for vblank
and stop calling cleanup_planes in commit_tail" patch series.
However that didn't solve the output issue.
I'm out of things to try to diagnose this, does anyone perhaps have an idea or
seen this issue
before?
Regards,
Wladimir van der Laan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Question about handling RGBA/BGRA in etnaviv driver
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. So back when etnaviv supported only BGRA, Mesa automatically picked that and everything was okay. However a recent patch added support for RGBA formats in etnaviv_format.c. Now, Mesa creates a real GL_RGBA texture when this is requested. This is all and well for rendering, however for anything using FBO to render to textures this is a problem. Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO. This fails now that GL_RGBA textures are really GL_RGBA, and it doesn't handle that error to fall back to something else so rendering issues ensue. I'm not sure how to handle this: - The quick fix would be to revert the RGBA formats patch, but the hardware supports rendering *from* RGBA textures fine so this would be throwing away a feature. - Another way would be to try to fix Qt to cope with this, and try e.g. GL_BGRA_EXT when it wants to render to a texture. Burdening the client code with this seems unintuitive to me. - Another hack would be to implement shader variants, and swap R/B in the pixel shader to emulate rendering to RGBA. Neither seems great. Does anyone have suggestions, do any of the other (gallium) drivers have this problem? Regards, Wladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] etnaviv: Generate new sin/cos instructions on GC3000
Shaders using sin/cos instructions were not working on GC3000.
The reason for this turns out to be that these chips implement sin/cos
in a different way (but using the same opcodes):
- Need their input scaled by 1/pi instead of 2/pi.
- Output an x and y component, which need to be multiplied to
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 <laa...@gmail.com>
---
src/gallium/drivers/etnaviv/etnaviv_compiler.c | 37 +-
src/gallium/drivers/etnaviv/etnaviv_internal.h | 2 ++
src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 ++
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index 59e1452..c4519e7 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -1444,7 +1444,42 @@ static void
trans_trig(const struct instr_translater *t, struct etna_compile *c,
const struct tgsi_full_instruction *inst, struct etna_inst_src *src)
{
- if (c->specs->has_sin_cos_sqrt) {
+ if (c->specs->has_new_sin_cos) { /* Alternative SIN/COS */
+ /* On newer chips alternative SIN/COS instructions are implemented,
+ * which:
+ * - Need their input scaled by 1/pi instead of 2/pi
+ * - Output an x and y component, which need to be multiplied to
+ * get the result
+ */
+ /* TGSI lowering should deal with SCS */
+ assert(inst->Instruction.Opcode != TGSI_OPCODE_SCS);
+
+ struct etna_native_reg temp = etna_compile_get_inner_temp(c); /* only
using .xyz */
+ emit_inst(c, &(struct etna_inst) {
+ .opcode = INST_OPCODE_MUL,
+ .sat = 0,
+ .dst = etna_native_to_dst(temp, INST_COMPS_Z),
+ .src[0] = src[0], /* any swizzling happens here */
+ .src[1] = alloc_imm_f32(c, 1.0f / M_PI),
+ });
+ emit_inst(c, &(struct etna_inst) {
+ .opcode = inst->Instruction.Opcode == TGSI_OPCODE_COS
+? INST_OPCODE_COS
+: INST_OPCODE_SIN,
+ .sat = 0,
+ .dst = etna_native_to_dst(temp, INST_COMPS_X | INST_COMPS_Y),
+ .src[2] = etna_native_to_src(temp, SWIZZLE(Z, Z, Z, Z)),
+ .tex = { .amode=1 }, /* Unknown bit needs to be set */
+ });
+ emit_inst(c, &(struct etna_inst) {
+ .opcode = INST_OPCODE_MUL,
+ .sat = inst->Instruction.Saturate,
+ .dst = convert_dst(c, >Dst[0]),
+ .src[0] = etna_native_to_src(temp, SWIZZLE(X, X, X, X)),
+ .src[1] = etna_native_to_src(temp, SWIZZLE(Y, Y, Y, Y)),
+ });
+
+ } else if (c->specs->has_sin_cos_sqrt) {
/* TGSI lowering should deal with SCS */
assert(inst->Instruction.Opcode != TGSI_OPCODE_SCS);
diff --git a/src/gallium/drivers/etnaviv/etnaviv_internal.h
b/src/gallium/drivers/etnaviv/etnaviv_internal.h
index f340116..2f09d55 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_internal.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_internal.h
@@ -70,6 +70,8 @@ struct etna_specs {
unsigned has_sign_floor_ceil : 1;
/* can use VS_RANGE, PS_RANGE registers*/
unsigned has_shader_range_registers : 1;
+ /* has the new sin/cos functions */
+ unsigned has_new_sin_cos : 1;
/* can use any kind of wrapping mode on npot textures */
unsigned npot_tex_any_wrap;
/* number of bits per TS tile */
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index 53a31c5..0af7078 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -620,6 +620,8 @@ etna_get_specs(struct etna_screen *screen)
screen->model >= 0x1000 || screen->model == 0x880;
screen->specs.npot_tex_any_wrap =
VIV_FEATURE(screen, chipMinorFeatures1, NON_POWER_OF_TWO);
+ screen->specs.has_new_sin_cos =
+ VIV_FEATURE(screen, chipMinorFeatures3, HAS_FAST_TRANSCENDENTALS);
if (instruction_count > 256) { /* unified instruction memory? */
screen->specs.vs_offset = 0xC000;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: add vivante tiled layout format modifiers
Reviewed-By: Wladimir J. van der Laan <laa...@gmail.com>
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 single buffer with multiple pixel pipes.
This is what the Vivante driver uses.
But it can't hurt reserving formats for them.
Wladimir
> > Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled
> > formats as well as so-called split-tiled variants for dual-pipe
> > hardware, where even and odd tiles start at different base addresses.
> >
> > Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
> > ---
> > include/uapi/drm/drm_fourcc.h | 41
> > +
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index a5890bf44c0af..ec0498cf61756 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -159,6 +159,7 @@ extern "C" {
> > #define DRM_FORMAT_MOD_VENDOR_NV 0x03
> > #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
> > #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
> > +#define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
> > /* add more to the end as needed */
> >
> > #define fourcc_mod_code(vendor, val) \
> > @@ -233,6 +234,46 @@ extern "C" {
> > */
> > #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
> >
> > +/* Vivante framebuffer modifiers */
> > +
> > +/*
> > + * Vivante 4x4 tiling layout
> > + *
> > + * This is a simple tiled layout using tiles of 4x4 pixels in a row-major
> > + * layout.
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_TILED
> > fourcc_mod_code(VIVANTE, 1)
> > +
> > +/*
> > + * Vivante 64x64 super-tiling layout
> > + *
> > + * This is a tiled layout using 64x64 pixel super-tiles, where each
> > super-tile
> > + * contains 8x4 groups of 2x4 tiles of 4x4 pixels (like above) each, all
> > in row-
> > + * major layout.
> > + *
> > + * For more information: see
> > + *
> > https://github.com/etnaviv/etna_viv/blob/master/doc/hardware.md#texture-tiling
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_SUPER_TILED fourcc_mod_code(VIVANTE, 2)
> > +
> > +/*
> > + * Vivante 4x4 tiling layout for dual-pipe
> > + *
> > + * Same as the 4x4 tiling layout, except every second 4x4 pixel tile
> > starts at a
> > + * different base address. Offsets from the base addresses are therefore
> > halved
> > + * compared to the non-split tiled layout.
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED fourcc_mod_code(VIVANTE, 3)
> > +
> > +/*
> > + * Vivante 64x64 super-tiling layout for dual-pipe
> > + *
> > + * Same as the 64x64 super-tiling layout, except every second 4x4 pixel
> > tile
> > + * starts at a different base address. Offsets from the base addresses are
> > + * therefore halved compared to the non-split super-tiled layout.
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE,
> > 4)
>
> Does this mean the dual-pipe stuff has 2 planes? Do you need Ville's
> driver-private format stuff for this?
>
> Also, someone else with clue needs to review this before I can pull it in
> :-)
> -Daniel
>
> > +
> > #if defined(__cplusplus)
> > }
> > #endif
> > --
> > 2.11.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/etnaviv: Set up initial PULSE_EATER register
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 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/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index cbb969e..6990a5d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -548,6 +548,37 @@ void etnaviv_gpu_start_fe(struct etnaviv_gpu *gpu, u32
address, u16 prefetch)
VIVS_FE_COMMAND_CONTROL_PREFETCH(prefetch));
}
+static void etnaviv_gpu_setup_pulse_eater(struct etnaviv_gpu *gpu)
+{
+ /*
+* base value for VIVS_PM_PULSE_EATER register on models where it
cannot be read,
+* from vivante kernel driver
+*/
+ u32 pulse_eater = 0x01590880;
+
+ if (etnaviv_is_model_rev(gpu, GC4000, 0x5208) ||
+ etnaviv_is_model_rev(gpu, GC4000, 0x5222)) {
+ pulse_eater |= BIT(23);
+ gpu_write(gpu, VIVS_PM_PULSE_EATER, pulse_eater);
+ }
+
+ if (etnaviv_is_model_rev(gpu, GC1000, 0x5039) ||
+ etnaviv_is_model_rev(gpu, GC1000, 0x5040)) {
+ pulse_eater &= ~BIT(16);
+ pulse_eater |= BIT(17);
+ gpu_write(gpu, VIVS_PM_PULSE_EATER, pulse_eater);
+ }
+
+ if ((gpu->identity.revision > 0x5420) &&
+(gpu->identity.features & chipFeatures_PIPE_3D))
+ {
+ /* disable internal DFS: this is extremely important to
performance */
+ pulse_eater = gpu_read(gpu, VIVS_PM_PULSE_EATER);
+ pulse_eater |= BIT(18);
+ gpu_write(gpu, VIVS_PM_PULSE_EATER, pulse_eater);
+ }
+}
+
static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
{
u16 prefetch;
@@ -588,6 +619,9 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
gpu_write(gpu, VIVS_MC_BUS_CONFIG, bus_config);
}
+ /* setup the pulse eater */
+ etnaviv_gpu_setup_pulse_eater(gpu);
+
/* setup the MMU */
etnaviv_iommu_restore(gpu);
--
2.7.4
[PATCH v2] drm/etnaviv: Add new GC3000 sensitive states
- Add PS.INST_ADDR (0x01028) and VS.INST_ADDR (0x0086C): GC3000 loads
shader code from these addresses if ICACHE is used.
- Add new NFE vertex stream addresses (0x14600).
- Add PE Multple Render Target pipe addresses (0x14800).
- Add TS Multiple Render Target pipe addresses (0x017C0, 0x17E0).
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/etnaviv_cmd_parser.c
index 2a2e5e3..6e3bbcf 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
@@ -56,6 +56,8 @@ static const struct {
ST(0x0644, 1),
ST(0x064c, 1),
ST(0x0680, 8),
+ ST(0x086c, 1),
+ ST(0x1028, 1),
ST(0x1410, 1),
ST(0x1430, 1),
ST(0x1458, 1),
@@ -73,8 +75,12 @@ static const struct {
ST(0x16c0, 8),
ST(0x16e0, 8),
ST(0x1740, 8),
+ ST(0x17c0, 8),
+ ST(0x17e0, 8),
ST(0x2400, 14 * 16),
ST(0x10800, 32 * 16),
+ ST(0x14600, 16),
+ ST(0x14800, 8 * 8),
#undef ST
};
--
2.7.4
[PATCH] drm/etnaviv: Add new GC3000 sensitive states
- 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/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
index 2a2e5e3..abb37c6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
@@ -56,6 +56,8 @@ static const struct {
ST(0x0644, 1),
ST(0x064c, 1),
ST(0x0680, 8),
+ ST(0x086c, 1),
+ ST(0x1028, 1),
ST(0x1410, 1),
ST(0x1430, 1),
ST(0x1458, 1),
@@ -75,6 +77,7 @@ static const struct {
ST(0x1740, 8),
ST(0x2400, 14 * 16),
ST(0x10800, 32 * 16),
+ ST(0x14600, 16),
#undef ST
};
--
2.7.4
[PATCH] drm/etnaviv: Set up initial PULSE_EATER register
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 performance (sped up
memory read performance by 7.5x and write performance by 1.5x) on an
affected GPU.
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 1e0ec81..e1a9d64 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -548,6 +548,9 @@ void etnaviv_gpu_start_fe(struct etnaviv_gpu *gpu, u32
address, u16 prefetch)
VIVS_FE_COMMAND_CONTROL_PREFETCH(prefetch));
}
+/* base value for VIVS_PM_PULSE_EATER register on models where it cannot be
read */
+#define PULSE_EATER_BASE_VALUE (0x01590880)
+
static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
{
u16 prefetch;
@@ -588,6 +591,33 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
gpu_write(gpu, VIVS_MC_BUS_CONFIG, bus_config);
}
+ /* set up the pulse eater */
+ if (etnaviv_is_model_rev(gpu, GC4000, 0x5208) ||
+ etnaviv_is_model_rev(gpu, GC4000, 0x5222)) {
+ /* undocumented workaround from vivante kernel driver */
+ u32 pulse_eater = PULSE_EATER_BASE_VALUE;
+ pulse_eater |= BIT(23);
+ gpu_write(gpu, VIVS_PM_PULSE_EATER, pulse_eater);
+ }
+
+ if (etnaviv_is_model_rev(gpu, GC1000, 0x5039) ||
+ etnaviv_is_model_rev(gpu, GC1000, 0x5040)) {
+ /* undocumented workaround from vivante kernel driver */
+ u32 pulse_eater = PULSE_EATER_BASE_VALUE;
+ pulse_eater &= ~BIT(16);
+ pulse_eater |= BIT(17);
+ gpu_write(gpu, VIVS_PM_PULSE_EATER, pulse_eater);
+ }
+
+ if ((gpu->identity.revision > 0x5420) &&
+(gpu->identity.features & chipFeatures_PIPE_3D))
+ {
+ /* disable internal DFS: this is extremely important to
performance */
+ u32 pulse_eater = gpu_read(gpu, VIVS_PM_PULSE_EATER);
+ pulse_eater |= BIT(18);
+ gpu_write(gpu, VIVS_PM_PULSE_EATER, pulse_eater);
+ }
+
/* setup the MMU */
etnaviv_iommu_restore(gpu);
--
2.7.4
etnaviv: mmu issue after end of address space reached?
> 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 buffer that this is happening for, but another bo used by the command buffer. > Blindly implementing the Vivante way does not seem like the correct > approach to me. I'm not suggesting that that is a good solution! Just needed to do that to narrow down the issue, as well as get rid of it for now. Regards, Wladimir
etnaviv: mmu issue after end of address space reached?
> 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 includes shader code and CL buffers) is - Send MMU flush command (like we do) - Add a notify event "resume" (they hardwire event 29 for this) - Add END command the command buffer so that the FE stops - Remember where to continue Then in the interrupt handler: - If the "resume" notify event comes in - Wait for FE to be idle - Restart the FE to the remembered position This is implemented in "pause" here http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c?id=77f61547834c4f127b44b13e43c59133a35880dc#n395 gcvPAGE_TABLE_DIRTY_BIT_FE is set here: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_mmu.c?id=77f61547834c4f127b44b13e43c59133a35880dc#n2176 endAfterFlushMmuCache is set here: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/gpu-viv/hal/kernel/arch/gc_hal_kernel_hardware.c?id=77f61547834c4f127b44b13e43c59133a35880dc#n1259 The interrupt notification is handled here: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_event.c?id=77f61547834c4f127b44b13e43c59133a35880dc#n2224 I hacked this into the DRM driver and have been running my test for quite some time, bumping against the tail end of the address range many times, without any MMU faults. My proposal is to add a bo flag for buffers that need this kind of "hard" MMU reset (this is not all of them, e.g. textures don't), and if their iova mapping requires a MMU flush, do the above stop-and-start ritual (in case of MMUv2). Wladimir
etnaviv: mmu issue after end of address space reached?
> <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 fault addr 0x > <3>[ 549.837744] etnaviv-gpu 13.gpu: MMU 3 fault addr 0x Okay I just tried to get the same while rendering in Mesa and it doesn't happen. It reaches the end of the address space, sets last_iova back to 0, and just continues. So the MMU fault is somehow specific to what I'm doing. Interesting. > What I find curious, though, is that after the search presumably starts over > at > 0 it returns 0xe8783000 instead of an earlier address. For this reason > last_iova is stuck near the end of the address space and the problem keeps > repeating once it's been hit. This does happen when rendering - it keeps dealing out iovas near the end of the address space. But that seems harmless, though maybe causes some more MMU flushes than necessary. Wladimir
etnaviv: mmu issue after end of address space reached?
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 - Submit command buffer - etna_cmd_stream_finish - Map buffer A, check output - Delete buffer A, B, C and D - Exit program (code is here: https://github.com/etnaviv/etnaviv_gpu_tests/blob/master/src/etnaviv_verifyops.c#L735) The curious thing is that after the fault happens once, it keeps running into the same fault almost immediately, even after a GPU reset. This made me suspect it has to do with kernel driver state not GPU state. I added some debugging in the kernel driver in etnaviv_iommu_find_iova: <4>[ 549.776209] Found iova: eff82000 <4>[ 549.780712] Found iova: eff93000 <4>[ 549.785173] Found iova: effa4000 <4>[ 549.789706] Found iova: effb5000 <4>[ 549.794167] Found iova: effc6000 <4>[ 549.798686] Found iova: effd7000 <4>[ 549.803171] Found iova: effe8000 <4>[ 549.803171] Found iova: effe8000 <4>[ 549.807680] last_iova <- end of range <4>[ 549.809966] Found iova: e8783000 <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 fault addr 0x <3>[ 549.837744] etnaviv-gpu 13.gpu: MMU 3 fault addr 0x Apparently it is running out of the address space. (I changed the end of the range to 0xf000 instead of 0x to rule out that it had to do with the GPU disliking certain addresses) In principle this shouldn't be an issue - after last_iova it starts over, with a flushed MMU. I verified that this flush is actually being queued in etnaviv_buffer_queue. However for some reason that logic doesn't seem to be working. I have not found out what is wrong yet. I have not verified whether the MMU flush is actually flushing, or whether this is a problem with updating the page tables. What I find curious, though, is that after the search presumably starts over at 0 it returns 0xe8783000 instead of an earlier address. For this reason last_iova is stuck near the end of the address space and the problem keeps repeating once it's been hit. It's certainly possible that I'm doing something dumb here and am somehow spamming full the address space :) Wladimir
[PATCH 08/10] drm/etnaviv: make it possible to reconfigure perf counter
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, readback->reg); > u32 *bo = readback->bo_vma; > > + if (readback->flags & ETNA_READBACK_PERF) > + gpu_write(gpu, readback->perf_reg, > readback->perf_value); > + > *(bo + readback->offset) = val; > } > } This is the wrong order. First write the selection register, then read the counter. Currently this causes the reported registers to be off by one, if they're read in sequential order. Wladimir
[PATCH] etnaviv: Cannot render to rb-swapped formats
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 swap in the resolve operation.
But this would be tricky to keep track of)
---
src/gallium/drivers/etnaviv/etnaviv_screen.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index c3f270d..06327b6 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -464,8 +464,11 @@ etna_screen_is_format_supported(struct pipe_screen
*pscreen,
return FALSE;
if (usage & PIPE_BIND_RENDER_TARGET) {
- /* if render target, must be RS-supported format */
- if (translate_rs_format(format) != ETNA_NO_MATCH) {
+ /* If render target, must be RS-supported format that is not rb swapped.
+ * Exposing rb swapped (or other swizzled) formats for rendering would
+ * involve swizzing in the pixel shader.
+ */
+ if (translate_rs_format(format) != ETNA_NO_MATCH &&
!translate_rs_format_rb_swap(format)) {
/* Validate MSAA; number of samples must be allowed, and render target
* must have MSAA'able format. */
if (sample_count > 1) {
--
2.7.4
[PATCH] drm/etnaviv: Allow DRAW_INSTANCED commands
Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the command stream to draw a number of instances of the same geometry. The information that has been figured out about the command can be found here: https://github.com/etnaviv/etna_viv/blob/master/rnndb/cmdstream.xml#L270 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 ++-- drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 1 + 2 files changed, 57 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/cmdstream.xml.h b/drivers/gpu/drm/etnaviv/cmdstream.xml.h index 8c44ba9..65f1ba1 100644 --- a/drivers/gpu/drm/etnaviv/cmdstream.xml.h +++ b/drivers/gpu/drm/etnaviv/cmdstream.xml.h @@ -8,10 +8,34 @@ This file was generated by the rules-ng-ng headergen tool in this git repository git clone git://0x04.net/rules-ng-ng The rules-ng-ng source files this header was generated from are: -- cmdstream.xml ( 12589 bytes, from 2014-02-17 14:57:56) -- common.xml( 18437 bytes, from 2015-03-25 11:27:41) - -Copyright (C) 2014 +- cmdstream.xml ( 14094 bytes, from 2016-11-11 06:55:14) +- copyright.xml ( 1597 bytes, from 2016-10-29 07:29:22) +- common.xml( 23344 bytes, from 2016-11-10 15:14:07) + +Copyright (C) 2012-2016 by the following authors: +- Wladimir J. van der Laan +- Christian Gmeiner +- Lucas Stach +- Russell King + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sub license, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the +next paragraph) shall be included in all copies or substantial portions +of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. */ @@ -26,6 +50,7 @@ Copyright (C) 2014 #define FE_OPCODE_STALL 0x0009 #define FE_OPCODE_CALL 0x000a #define FE_OPCODE_RETURN 0x000b +#define FE_OPCODE_DRAW_INSTANCED 0x000c #define FE_OPCODE_CHIP_SELECT 0x000d #define PRIMITIVE_TYPE_POINTS 0x0001 #define PRIMITIVE_TYPE_LINES 0x0002 @@ -214,5 +239,32 @@ Copyright (C) 2014 #define VIV_FE_CHIP_SELECT_HEADER_ENABLE_CHIP1 0x0002 #define VIV_FE_CHIP_SELECT_HEADER_ENABLE_CHIP0 0x0001 +#define VIV_FE_DRAW_INSTANCED 0x + +#define VIV_FE_DRAW_INSTANCED_HEADER 0x +#define VIV_FE_DRAW_INSTANCED_HEADER_OP__MASK 0xf800 +#define VIV_FE_DRAW_INSTANCED_HEADER_OP__SHIFT 27 +#define VIV_FE_DRAW_INSTANCED_HEADER_OP_DRAW_INSTANCED 0x6000 +#define VIV_FE_DRAW_INSTANCED_HEADER_INDEXED 0x0010 +#define VIV_FE_DRAW_INSTANCED_HEADER_TYPE__MASK 0x000f +#define VIV_FE_DRAW_INSTANCED_HEADER_TYPE__SHIFT 16 +#define VIV_FE_DRAW_INSTANCED_HEADER_TYPE(x) (((x) << VIV_FE_DRAW_INSTANCED_HEADER_TYPE__SHIFT) & VIV_FE_DRAW_INSTANCED_HEADER_TYPE__MASK) +#define VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__MASK 0x +#define VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__SHIFT 0 +#define VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO(x) (((x) << VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__SHIFT) & VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__MASK) + +#define VIV_FE_DRAW_INSTANCED_COUNT0x0004 +#define VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__MASK0xff00 +#define VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__SHIFT 24 +#define VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI(x) (((x) << VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__SHIFT) & VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__MASK) +#define VIV_FE_DRAW_INSTANCED_CO
imx-drm hang issue with etnaviv (GC3000)
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 rendering to work again after the crash is to reboot. Repeated tries only get the "flip_done timed out". This always happens while the program is exiting. Versions: - mesa: https://github.com/etnaviv/mesa 9a09984 - libdrm: https://cgit.freedesktop.org/mesa/drm/ fe4579e - Kernel: 4.8.0 or 4.8.4 + Pengutronix patches (20161007). Does anyone have an idea what could be the problem? Regards, Wladimir van der Laan [ 130.026973] [ cut here ] [ 130.031630] WARNING: CPU: 1 PID: 222 at drivers/gpu/drm/drm_atomic_helper.c:1127 drm_atomic_helper_wait_for_vblanks+0x1e4/0x200 [ 130.043149] [CRTC:24] vblank wait timed out [ 130.047367] Modules linked in: hid_generic usbhid hid ci_hdrc_imx ci_hdrc extcon_core ehci_hcd usbcore usb_common usbmisc_imx coda videobuf2_vmalloc [ 130.060915] CPU: 1 PID: 222 Comm: kmscube Not tainted 4.8.4+ #1 [ 130.066844] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 130.073378] Backtrace: [ 130.075863] [<8010b6c0>] (dump_backtrace) from [<8010b908>] (show_stack+0x20/0x24) [ 130.083439] r7:80b441d8 r6:600c0013 r5: r4:80b441d8 [ 130.089187] [<8010b8e8>] (show_stack) from [<803a33fc>] (dump_stack+0x78/0x94) [ 130.096422] [<803a3384>] (dump_stack) from [<8011a9b8>] (__warn+0xdc/0x110) [ 130.103389] r7:0009 r6:8042fda4 r5: r4:ed47fd08 [ 130.109132] [<8011a8dc>] (__warn) from [<8011aa34>] (warn_slowpath_fmt+0x48/0x50) [ 130.116620] r9: r8:ee1b9418 r7:edc76600 r6: r5:edffc500 r4: [ 130.124470] [<8011a9f0>] (warn_slowpath_fmt) from [<8042fda4>] (drm_atomic_helper_wait_for_vblanks+0x1e4/0x200) [ 130.134563] r3:0018 r2:80898166 [ 130.138194] [<8042fbc0>] (drm_atomic_helper_wait_for_vblanks) from [<80457fc8>] (imx_drm_atomic_commit_tail+0x58/0x68) [ 130.148895] r10:8086686b r9:ee1b923c r8:003f r7:80b6bf22 r6: r5:ee1b9000 [ 130.156823] r4:edffc500 [ 130.159390] [<80457f70>] (imx_drm_atomic_commit_tail) from [<804323e8>] (commit_tail+0x4c/0x68) [ 130.168094] r5:80b4a014 r4:edffc500 [ 130.171719] [<8043239c>] (commit_tail) from [<8043249c>] (drm_atomic_helper_commit+0x98/0xb0) [ 130.180249] r5: r4:edffc500 [ 130.183875] [<80432404>] (drm_atomic_helper_commit) from [<8045810c>] (imx_drm_atomic_commit+0x134/0x144) [ 130.193447] r7:80b6bf22 r6:edffc800 r5:edffc500 r4:0006 [ 130.199191] [<80457fd8>] (imx_drm_atomic_commit) from [<804556d0>] (drm_atomic_commit+0x60/0x70) [ 130.207981] r10:0004 r9:ee1b923c r8:003f r7:ee1b9000 r6:edffc500 r5:ee1b9000 [ 130.215908] r4:edffc500 [ 130.218475] [<80455670>] (drm_atomic_commit) from [<80435660>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x130/0x29c) [ 130.229175] r5:eeba9f00 r4: [ 130.232799] [<80435530>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<80436904>] (drm_fbdev_cma_restore_mode+0x20/0x24) [ 130.244107] r10:400c0013 r9:ede68f88 r8:ee2053c0 r7:ee1b911c r6:ede68f7c r5:80bc5648 [ 130.252033] r4:ee1b9000 [ 130.254598] [<804368e4>] (drm_fbdev_cma_restore_mode) from [<804581e8>] (imx_drm_driver_lastclose+0x20/0x24) [ 130.264439] [<804581c8>] (imx_drm_driver_lastclose) from [<8043a5b0>] (drm_lastclose+0x4c/0xfc) [ 130.273149] [<8043a564>] (drm_lastclose) from [<8043a938>] (drm_release+0x2d8/0x324) [ 130.280898] r7:ee1b911c r6:ede68f7c r5:ede68f00 r4:ee1b9000 [ 130.286642] [<8043a660>] (drm_release) from [<801fa8a8>] (__fput+0xe8/0x1bc) [ 130.293696] r10:ede069c8 r9:0008 r8:ee21b190 r7:ee428ee0 r6: r5:ee197bc0 [ 130.301622] r4:ede069c0 [ 130.304183] [<801fa7c0>] (__fput) from [<801fa9ec>] (fput+0x18/0x1c) [ 130.310890] r10: r9: r8:80107ac4 r7:ed47ff58 r6:edf36a80 r5:80b70eb8 [ 130.318817] r4:ee0bf800 [ 130.321381] [<801fa9d4>] (fput) from [<80134e6c>] (task_work_run+0xc8/0xdc) [ 130.328704] [<80134da4>] (task_work_run) from [<8011caec>] (do_exit+0x438/0x960) [ 130.336105] r7:ed47ff58 r6:ee0bfc08 r5:eeb88a80 r4:ee0bf800 [ 130.341847] [<8011c6b4>] (do_exit) from [<8011e188>] (do_group_exit+0x5c/0xcc) [ 130.349075] r7:e000 [ 130.351638] [<8011e12c>] (do_group_exit) from [<8011e218>] (__wake_up_parent+0x0/0x30) [ 130.359560] r7:00f8 r6:76ec6750 r5:0001 r4:0001 [ 130.365305] [<8011e1f8>] (SyS_exit_group) from [<80107900>] (ret_fast_syscall+0x0/0x3c) [ 130.373357] ---[ end trace 5678aedcbb762e5c ]--- [ 140.667136] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out [ 150.907117] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out [ 161.147143] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0]
