DisplayLink UDL driver with Intel IOMMU enabled

2020-01-13 Thread Volker Vogelhuber 
I just came across a DMAR allocation issue when I wanted to use the UDL 
driver with a DL-165 chipset and had the Intel IOMMU enabled.


It seems like it could be solved with the same patch already applied to 
the EVDI driver: 
https://github.com/DisplayLink/evdi/commit/74e289906dba95c0ad3208cfa6a57ba3042b930f


So just add interface->dev.archdata.iommu = INTEL_IOMMU_DUMMY_DOMAIN;
before the drm_dev_alloc call in udl_drv.c seems to be enough to use
the UDL driver with IOMMU enabled.

Kind regards,
   Volker

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 10bit output via KMS

2017-08-02 Thread Volker Vogelhuber 


Hi,
 >>> On 24 July 2017 at 14:56, Volker Vogelhuber >>> 
<v.vogelhu...@digitalendoscopy.de> wrote: >>>> I wonder if it is 
possible to have drmModeAddFB2 to handle >>>> 'X', 'R', '3', '0' at all. 
So is this supported in any way? >>> Secondly, you're correct that you 
would need (theoretically) to extend >>> drmModeAddFB2, however it 
already has DRM_FORMAT_XRGB2101010 and >>> DRM_FORMAT_XBGR2101010 for 
i965 and above, which covers everything in >>> the last 10 years. This 
is the 'XR30' FourCC you mention, so it should >>> already be there and 
working in the kernel. >> This question probably better fits to the drm 
mailing list, although the >> discussion started on the mesa list. >> >> 
I got it working now that my 10bit buffers are correctly displayed >> on 
a Samsung QM49F via drmModeAddFB2 and the 'X', 'R', '3', '0' >> fourcc 
code. Based on the Samsung's datasheet it should support 10bit >> 
signals, although the EDID does not seem to contain a vendor >> specific 
data block that would confirm that assumption. >> >> I have connected an 
Apollo Lake module with a display port cable >> to that display but I'm 
unsure if it's really 10bit or if there is some >> conversion logic 
somewhere in between that may downsample my >> 10 bit buffer to 8bit 
before sending it via displayport to the display. > > Well you could 
just try to display a 10bit image with a gradient going from black to 
white. > The difference between 8bit and 10bit should be obvious even to 
the naked eye. Thanks Christian. I tried your proposal but as I already 
assumed there

seem to be no difference. I switched the display to an LG 27UD58-B
which supports the vendor specific data block and also states that
it supports 36bpp as well as 30bpp input signals. It even has a deep
color option to be enabled in it's menu. But apparently the apollo
lake GPU does not care about that, or at least it makes no
difference regarding my test buffer. What I verified is that the
buffer generated by OpenGL is really 10bit. When I pass the 10bit
buffer to drmModeAddFB2 as an 8bit buffer it is shown with various
color artifacts because of the wrong bit mapping.

I just stumbled upon a slide from Andy Ritger where he mentions
that there are some components still missing for HDR10.
(https://www.x.org/wiki/Events/XDC2016/Program/xdc-2016-hdr.pdf)
As far as I understand it, he proposes that the driver should
accept an scRGB FP16 buffer and that this part is still missing in
the Linux kernel. My question is: is that only true for HDR10
with regards to SMPTE 2086, or is it even not possible to
output a "deep color" DRM_FORMAT_XBGR2101010 buffer as
a 10bit BPP signal via displayport.



So far I stumbled over some patches regarding color management  >> in the drm part of the kernel, but couldn't figure out how one 
could >> configure what is really send to the display. It seem to mostly 
be used to manipulate gamma values and so on. As the only indicator >> 
what is provided to the display is the buffer format handled by >> 
drmModeAddFB2 I doubt this is enough to configure the signal. >> 
Otherwise one could argue that the link speed of the display signal >> 
would have to toggle every time I send a different buffer format, which 
is certainly not the case. So what portion of the kms/drm chain do I >> 
miss currently? The drmModeModeInfo pointer has a clock field, but I 
guess this is meant to be for the pixel clock not the clock of the 
serialized signal. Probably that's why I couldn't find modelines for 
4k@60 especially for 10bit compared to 8bit. >> >> Thanks >> Volker >> 
>> >> >> ___ >> 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

Re: 10bit output via KMS

2017-07-28 Thread Volker Vogelhuber 

Hi,


On 24 July 2017 at 14:56, Volker Vogelhuber
<v.vogelhu...@digitalendoscopy.de> wrote:

I wonder if it is possible to have drmModeAddFB2 to handle
'X', 'R', '3', '0' at all. So is this supported in any way?

Secondly, you're correct that you would need (theoretically) to extend
drmModeAddFB2, however it already has DRM_FORMAT_XRGB2101010 and
DRM_FORMAT_XBGR2101010 for i965 and above, which covers everything in
the last 10 years. This is the 'XR30' FourCC you mention, so it should
already be there and working in the kernel.

This question probably better fits to the drm mailing list, although the
discussion started on the mesa list.

I got it working now that my 10bit buffers are correctly displayed
on a Samsung QM49F via drmModeAddFB2 and the 'X', 'R', '3', '0'
fourcc code. Based on the Samsung's datasheet it should support 10bit
signals, although the EDID does not seem to contain a vendor
specific data block that would confirm that assumption.

I have connected an Apollo Lake module with a display port cable
to that display but I'm unsure if it's really 10bit or if there is some
conversion logic somewhere in between that may downsample my
10 bit buffer to 8bit before sending it via displayport to the display.
So far I stumbled over some patches regarding color management
in the drm part of the kernel, but couldn't figure out how one could
configure what is really send to the display. It seem to mostly be used 
to manipulate gamma values and so on. As the only indicator

what is provided to the display is the buffer format handled by
drmModeAddFB2 I doubt this is enough to configure the signal.
Otherwise one could argue that the link speed of the display signal
would have to toggle every time I send a different buffer format, which 
is certainly not the case. So what portion of the kms/drm chain do I
miss currently? The drmModeModeInfo pointer has a clock field, but I 
guess this is meant to be for the pixel clock not the clock of the 
serialized signal. Probably that's why I couldn't find modelines for 
4k@60 especially for 10bit compared to 8bit.


Thanks
   Volker



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

10bit output via KMS

2017-07-24 Thread Volker Vogelhuber 

I have implemented a display manager application that takes DMB-BUF FDs
from another process and presents them to a connected output display
using the KMS infrastructure (drmModeAddFB, etc.). So far this works
without problems for XRGB. Now I wanted to have 10bit color depth
per channel. I created a FBO with 10bit (by patching the mesa and ex-
ported it's texture as a file descriptor via eglExportDMABUFImageMESA,
see attached patch).
When I try to import that file descriptor via gbm_bo_import it fails
because in gbm_bo_import, createImageFromFds is called which compares
the format passed to gbm_bo_import with intel_image_formats. But this
array does not seem to support 10bit formats. Now I wonder how one
could output 10bit per color channel to an output connector?


---
 include/EGL/eglext.h |  4 
 src/egl/drivers/dri2/egl_dri2.c  | 26 +-
 src/gbm/backends/dri/gbm_dri.c   |  3 +++
 src/mesa/drivers/dri/i965/intel_screen.c |  2 ++
 4 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index bc8f0ba..c0d55e9 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -862,10 +862,14 @@ EGLAPI EGLSurface EGLAPIENTRY 
eglCreatePixmapSurfaceHI (EGLDisplay dpy, EGLConfi

 #define EGL_DRM_BUFFER_FORMAT_MESA0x31D0
 #define EGL_DRM_BUFFER_USE_MESA   0x31D1
 #define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2
+#define EGL_DRM_BUFFER_FORMAT_RGB10A2_MESA 0x31D9
+#define EGL_DRM_BUFFER_FORMAT_R8_MESA 0x31E0
+#define EGL_DRM_BUFFER_FORMAT_GR88_MESA   0x31E1
 #define EGL_DRM_BUFFER_MESA   0x31D3
 #define EGL_DRM_BUFFER_STRIDE_MESA0x31D4
 #define EGL_DRM_BUFFER_USE_SCANOUT_MESA   0x0001
 #define EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002
+#define EGL_DRM_BUFFER_USE_LINEAR 0x0008
 typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESAPROC) 
(EGLDisplay dpy, const EGLint *attrib_list);
 typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESAPROC) 
(EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint 
*stride);

 #ifdef EGL_EGLEXT_PROTOTYPES
diff --git a/src/egl/drivers/dri2/egl_dri2.c 
b/src/egl/drivers/dri2/egl_dri2.c

index 2cab7d0..39394b0 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1921,6 +1921,18 @@ dri2_create_image_mesa_drm_buffer(_EGLDisplay 
*disp, _EGLContext *ctx,

   format = __DRI_IMAGE_FORMAT_ARGB;
   pitch = attrs.DRMBufferStrideMESA;
   break;
+   case EGL_DRM_BUFFER_FORMAT_RGB10A2_MESA:
+  format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  pitch = attrs.DRMBufferStrideMESA;
+  break;
+   case EGL_DRM_BUFFER_FORMAT_R8_MESA:
+  format = __DRI_IMAGE_FORMAT_R8;
+  pitch = attrs.DRMBufferStrideMESA;
+  break;
+case EGL_DRM_BUFFER_FORMAT_GR88_MESA:
+  format = __DRI_IMAGE_FORMAT_GR88;
+  pitch = attrs.DRMBufferStrideMESA;
+  break;
default:
   _eglError(EGL_BAD_PARAMETER,
 "dri2_create_image_khr: unsupported pixmap depth");
@@ -2216,6 +2228,15 @@ dri2_create_drm_image_mesa(_EGLDriver *drv, 
_EGLDisplay *disp,

case EGL_DRM_BUFFER_FORMAT_ARGB32_MESA:
   format = __DRI_IMAGE_FORMAT_ARGB;
   break;
+   case EGL_DRM_BUFFER_FORMAT_RGB10A2_MESA:
+  format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  break;
+   case EGL_DRM_BUFFER_FORMAT_R8_MESA:
+  format = __DRI_IMAGE_FORMAT_R8;
+  break;
+   case EGL_DRM_BUFFER_FORMAT_GR88_MESA:
+  format = __DRI_IMAGE_FORMAT_GR88;
+  break;
default:
   _eglLog(_EGL_WARNING, "bad image format value 0x%04x",
 attrs.DRMBufferFormatMESA);
@@ -2225,7 +2246,8 @@ dri2_create_drm_image_mesa(_EGLDriver *drv, 
_EGLDisplay *disp,

valid_mask =
   EGL_DRM_BUFFER_USE_SCANOUT_MESA |
   EGL_DRM_BUFFER_USE_SHARE_MESA |
-  EGL_DRM_BUFFER_USE_CURSOR_MESA;
+  EGL_DRM_BUFFER_USE_CURSOR_MESA |
+  EGL_DRM_BUFFER_USE_LINEAR;
if (attrs.DRMBufferUseMESA & ~valid_mask) {
   _eglLog(_EGL_WARNING, "bad image use bit 0x%04x",
 attrs.DRMBufferUseMESA & ~valid_mask);
@@ -2239,6 +2261,8 @@ dri2_create_drm_image_mesa(_EGLDriver *drv, 
_EGLDisplay *disp,

   dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (attrs.DRMBufferUseMESA & EGL_DRM_BUFFER_USE_CURSOR_MESA)
   dri_use |= __DRI_IMAGE_USE_CURSOR;
+   if (attrs.DRMBufferUseMESA & EGL_DRM_BUFFER_USE_LINEAR)
+  dri_use |= __DRI_IMAGE_USE_LINEAR;

dri2_img->dri_image =
   dri2_dpy->image->createImage(dri2_dpy->dri_screen,
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 71590d7..fdad65a 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -817,6 +817,9 @@ gbm_dri_to_gbm_format(uint32_t dri_format)
case __DRI_IMAGE_FORMAT_ABGR:
   ret = GBM_FORMAT_ABGR;
   break;
+   case __DRI_IMAGE_FORMAT_ARGB2101010:
+  ret = GBM_FORMAT_ARGB2101010;
+  break;

Sampling DRM_FORMAT_YUYV in GLSL

2017-05-08 Thread Volker Vogelhuber 

I'm currently trying to render an V4L2 image with OpenGL
on an Intel Apollo Lake using Linux 4.10 and Mesa 13.
Supprisingly I noticed that importing a DMABUF with format
DRM_FORMAT_YUYV into OpenGL using
 eglCreateImage/glEGLImageTargetTexture2DOES
worked out of the box. But I noticed that there seem to be a split into
two textures when importing the buffer. At least the nplanes
variable in the __DRIimage's planar_format is set to 2 and in the
intel_screen.c there is a comment for __DRI_IMAGE_FOURCC_YUYV:
"For YUYV buffers, we set up two overlapping DRI images
 and treat them as planar buffers in the compositors."
So far so good, but how do I access the second texture in the GLSL
shader. I only created one texture object before calling
glEGLImageTargetTexture2DOES with the EGLImage I got from
eglCreateImage. And using texture( source, texCoord ) on this
texture samples only the Y and U channel, what seems obvious
as the texture is created as GL_RG texture.
Can anyone explain to me, how one accesses the second plane.
And if there is an example somewhere how the two planes
have to be sampled to convert the values back to RGB, it would
be nice if someone can send a link to such an example.

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

AW: mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA

2017-02-02 Thread Volker Vogelhuber 


On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to mmap the memory of an OpenGL texture I've created by
>> doing the following:
>> 
>> std::vector image_attribs = {
>>         EGL_WIDTH,  static_cast(m_texWidth & 0x7FFF),
>>         EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
>>         EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
>>         EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
>>         EGL_NONE
>>     };
>> glGenTextures( 1,  );
>> glBindTexture( GL_TEXTURE_2D, texID );
>> eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), _attribs[0]
>> );
>> glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
>> eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, ,
>> , )
>> eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, , strides,
>> offsets)
>>
>> struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
>> ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
>> mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
>>
>> For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
>> while
>> using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 on
>> an Intel CherryTrail (i915).
>>
>> Is there an obvious reason why I'm not able to mmap the texture FD with
>> PROT_WRITE flags?
>> Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I would
>> have guessed that
>> this should be possible. Or is it only true for specific GEM buffers not
>> textures created using
>> eglCreateDRMImageMESA?
>
>From a quick look the mesa/libdrm (depending upon driver) handle2fd
>implementations don't set the DRM_RDWR flag when asking PRIME for a
>dma-buf fd, which means you fd doesn't have write permissions. Which means
>mmap with writing allowed will fail.
>
>Not sure how to fix that.
Thanks for the reply. I guess you mean that line of code: 
http://code.metager.de/source/xref/freedesktop/mesa/drm/intel/intel_bufmgr_gem.c#2679
Is there a good reason not to patch drm_intel_bo_gem_export_to_prime to call 
drmPrimeHandleToFD with DRM_RDWR flag set as well? I just saw a similar 
discussion
under https://chromium-review.googlesource.com/c/323990/


Regards,
    Volker


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA

2017-02-02 Thread Volker Vogelhuber 

Hi,

I'm currently trying to mmap the memory of an OpenGL texture I've 
created by

doing the following:

std::vector image_attribs = {
EGL_WIDTH,  static_cast(m_texWidth & 0x7FFF),
EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
EGL_NONE
};
glGenTextures( 1,  );
glBindTexture( GL_TEXTURE_2D, texID );
eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), 
_attribs[0] );

glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, , 
, )
eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, , strides, 
offsets)


struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );

For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag, 
while
using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 
on an Intel CherryTrail (i915).


Is there an obvious reason why I'm not able to mmap the texture FD with 
PROT_WRITE flags?
Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I 
would have guessed that
this should be possible. Or is it only true for specific GEM buffers not 
textures created using

eglCreateDRMImageMESA?

Regards,
Volker

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 dma_map_sg return value

2015-05-05 Thread Volker Vogelhuber 
On 05.05.2015 17:51, Daniel Vetter wrote:
> On Tue, May 05, 2015 at 09:42:44AM +0200, Volker Vogelhuber wrote:
>> The documentation of the DMA-API writes the following about
>> dma_map_sg:
>>
>> "The implementation is free to merge several consecutive sglist entries
>> into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
>> consecutive sglist entries can be merged into one provided the first one
>> ends and the second one starts on a page boundary - in fact this is a huge
>> advantage for cards which either cannot do scatter-gather or have very
>> limited number of scatter-gather entries) and returns the actual number
>> of sg entries it mapped them to."
>>
>> I wonder why the return value of dma_map_sg is not returned in any way
>> from i915_gem_map_dma_buf. It only uses the return value for error
>> checking.
>> Can one be sure that in case of the i915 the nents value of the scatter
>> gather table is always equal to the value returned by dma_map_sg?
>> I'm asking because I want to use the sg table returned by
>> i915_gem_map_dma_buf in my own kernel module and iterate over it
>> using for_each_sg. And the example in the documentation of the DMA-API
>> uses the return value of dma_map_sg when calling for_each_sg and not
>> nents and it explicitly mentions:
>>
>> "Then you should loop count times (note: this can be less than nents times)"
> Hm, not looking at the return value of dma_map_sg is also how we use it
> internally in i915_gem_gtt.c. Not sure why we get away with this ...
Maybe you can be sure that on systems where the i915 driver is
used no reduction of the nents will be done by dma_map_sg?

Regards,
Volker

i915 dma_map_sg return value

2015-05-05 Thread Volker Vogelhuber 
The documentation of the DMA-API writes the following about
dma_map_sg:

"The implementation is free to merge several consecutive sglist entries
into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
consecutive sglist entries can be merged into one provided the first one
ends and the second one starts on a page boundary - in fact this is a huge
advantage for cards which either cannot do scatter-gather or have very
limited number of scatter-gather entries) and returns the actual number
of sg entries it mapped them to."

I wonder why the return value of dma_map_sg is not returned in any way
from i915_gem_map_dma_buf. It only uses the return value for error
checking.
Can one be sure that in case of the i915 the nents value of the scatter
gather table is always equal to the value returned by dma_map_sg?
I'm asking because I want to use the sg table returned by
i915_gem_map_dma_buf in my own kernel module and iterate over it
using for_each_sg. And the example in the documentation of the DMA-API
uses the return value of dma_map_sg when calling for_each_sg and not
nents and it explicitly mentions:

"Then you should loop count times (note: this can be less than nents times)"

Regards,
 Volker

Using EGLImage textures imported via dma-buf with E3845 baytrail

2015-04-28 Thread Volker Vogelhuber 
I'm still fighting with the zero copy rendering of graphics data sent by 
an FPGA to my system memory.
Basically what I've done so far is writing a kernel module based on TI's 
CMEM only simpler, reserving
memory for that module during boot up using kernel command line parameter
memmap=256M$0x6000 and provide a DMA-BUF implementation for 
accessing those buffers.

After allocation of a region within that area I created an EGLImage by 
using the DMA-BUF file
descriptor I got from my module. So far rendering of that EGLImage as a 
texture within OpenGL
seems to work OK. But of course one buffer is not enough as we have to 
get FPGA writes and
GPU reads in sync. Unfortunately here's where trouble starts.

I stripped down a test case as much as I could that allocates three 
textures bound to an EGLImage
Those textures are filled with a pattern in different colors. When I 
start rendering everything is ok.
By pressing 'R' key the next texture will be rendered. First also the 
second texture is rendered ok
and finally the third. But after switching from the third back to the 
first, it seems like it's rendering
always the third. In another test scenario in-house we had the effect 
that the GPU seemed to read
from the wrong address after one buffer cycle. But in that case only for 
the first texture.
So the effect might not directly relate to the root cause for that problem.
Using the same code with GPU allocated textures works as expected 
(switchable in the example
using preprocessor define EGL_TEXTURE)

Additionally if we bind an EGLImage from an DMA-BUF fd to a render 
buffer and want to render into
that buffer we got GPU hang errors. Changing the FBO to be bound to a 
normal texture allocated
by the GPU driver everything is OK. So something weird is going on for 
all access to DMA-BUF based
EGLImages.

We're currently using linux-stable 4.0 (but also tested that with 3.17 
and 3.19 with the same effects) and
mesa master rev 9143940da2c4f0deb07d01c1b48d16bb16022997. We first had 
used mesa 10.4.4
with a patch to allow writing into a EGLImage based on a DMA-BUF but 
this has been officially enabled
now in current master (see 
http://comments.gmane.org/gmane.comp.video.mesa3d.devel/100090).
But the problems seem to be unrelated to all those changes.

Attached is the demo code (including the kernel module and some CMake 
build files). Not in production
state but should be usable.

In case binary file attachments are stripped from the mailing list I 
also uploaded it under
http://expirebox.com/download/f618275a39ee118bf2f9d01645d23336.html
but this link expires in 48 hours.

I would be very grateful for any hint, what's going wrong.

Regards,
 Volker

-- next part --
A non-text attachment was scrubbed...
Name: DRMTest.tar.gz
Type: application/gzip
Size: 28468 bytes
Desc: not available
URL:

What happened to the patch for module reference counting when using dma-buf API

2015-04-22 Thread Volker Vogelhuber 
I just stumbled across the same problem the patch from Tomasz 
Stanislawski (https://lkml.org/lkml/2012/8/8/163) would solve over two 
years ago. But it seems like it hasn't been merged into mainline. Why 
not? Is there any other possibility to avoid modules being released 
while other modules still use dma buffers of that module?

regards,
Volker

Update front buffer without CPU interaction?

2015-03-24 Thread Volker Vogelhuber 


On 23.02.2015 10:18, Daniel Vetter wrote:
> On Mon, Feb 23, 2015 at 09:22:56AM +0100, Volker Vogelhuber wrote:
>> On 22.02.2015 12:52, Daniel Vetter wrote:
>>> On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote:
>>>> I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845
>>>> cpu.
>>>> In our product we want to have an FPGA streaming video images to a
>>>> predefined memory area using bus master dma and render those images using
>>>> OpenGL. So far this works in a preliminary state.
>>>> We now have the security requirement that in case the CPU (software/kernel
>>>> driver) crashes for what ever reason, the GPU display signal should still
>>>> output at least the video images (obviously any additional render stuff 
>>>> will
>>>> not be available anymore). My question is now, would it be possible to get
>>>> the physical address of the DRM front buffer, so that I can provide this
>>>> address to the FPGA (connected via PCIe) and is it possible to have the GPU
>>>> still reading the last front buffer for the display output while the FPGA
>>>> writes to that area. So I would think that the GPU has some kind of DMA
>>>> engine running, that continuously reading the last front buffer until
>>>> switched to another buffer by the CPU. So even if the CPU does not control
>>>> the GPU anymore, it might be possible to have the front buffer updated by
>>>> the FPGA directly. Of course there will be tearing artefacts as no VSYNC
>>>> will be available but that wouldn't be an issue so far.
>>> Just share buffers between your fpga driver and the i915 driver using
>>> prime/dma-buf and before each pageflip tell your fpga driver to render
>>> into the new buffer. We don't have any interfaces to tell userspace
>>> physical addresses of anything, and that's fairly intentional - the kernel
>>> is and must be in control of memory management.
>>> -Daniel
>> Thanks for the reply. I already stumbled across the PRIME way to get access
>> to the buffer within the source code but it wasn't totally clear to me, how
>> one would access this API.
>> I guess one have to call drmPrimeHandleToFD with the /dev/dri/card0 file
>> descriptor, a gem handle (probably retrieved using gbm_bo_get_handle),
>> DRM_CLOEXEC and some output variable.
>> The Prime file descriptor returned, should be usable with the dma-buf API,
>> right? So I can call dma_buf_get(prime_fd) within the FPGA driver and pass
>> the sg_table I get from dma_buf_map_attachment to the DMA engine within the
>> FPGA.
>> Does this concept work in theory? Or did I miss something?
> It should work even in practice ;-) And yeah description of the dance
> looks complete.
>
>
I haven't implemented all of the proposed flow (only did a quick writing 
test into the framebuffer from within the FPGA driver using the CPU) but 
it worked more or less without any problems when using an intel 
baytrail. On an AMD G-Series GX-412HC the API seems to be implemented as 
well, but during the call of dma_buf_map_attachment there is a NULL 
pointer exception within the call to radeon_gem_prime_get_sg_table. It 
seems like bo->tbo is a null pointer (used kernel 3.19). Do I have to do 
anything differently when using the radeon driver, or isn't it supported 
at all for this card?

Update front buffer without CPU interaction?

2015-02-23 Thread Volker Vogelhuber 

On 22.02.2015 12:52, Daniel Vetter wrote:
> On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845
>> cpu.
>> In our product we want to have an FPGA streaming video images to a
>> predefined memory area using bus master dma and render those images using
>> OpenGL. So far this works in a preliminary state.
>> We now have the security requirement that in case the CPU (software/kernel
>> driver) crashes for what ever reason, the GPU display signal should still
>> output at least the video images (obviously any additional render stuff will
>> not be available anymore). My question is now, would it be possible to get
>> the physical address of the DRM front buffer, so that I can provide this
>> address to the FPGA (connected via PCIe) and is it possible to have the GPU
>> still reading the last front buffer for the display output while the FPGA
>> writes to that area. So I would think that the GPU has some kind of DMA
>> engine running, that continuously reading the last front buffer until
>> switched to another buffer by the CPU. So even if the CPU does not control
>> the GPU anymore, it might be possible to have the front buffer updated by
>> the FPGA directly. Of course there will be tearing artefacts as no VSYNC
>> will be available but that wouldn't be an issue so far.
> Just share buffers between your fpga driver and the i915 driver using
> prime/dma-buf and before each pageflip tell your fpga driver to render
> into the new buffer. We don't have any interfaces to tell userspace
> physical addresses of anything, and that's fairly intentional - the kernel
> is and must be in control of memory management.
> -Daniel
Thanks for the reply. I already stumbled across the PRIME way to get 
access to the buffer within the source code but it wasn't totally clear 
to me, how one would access this API.
I guess one have to call drmPrimeHandleToFD with the /dev/dri/card0 file 
descriptor, a gem handle (probably retrieved using gbm_bo_get_handle), 
DRM_CLOEXEC and some output variable.
The Prime file descriptor returned, should be usable with the dma-buf 
API, right? So I can call dma_buf_get(prime_fd) within the FPGA driver 
and pass the sg_table I get from dma_buf_map_attachment to the DMA 
engine within the FPGA.
Does this concept work in theory? Or did I miss something?

Regards, Volker

Update front buffer without CPU interaction?

2015-02-16 Thread Volker Vogelhuber 
I'm currently trying to setup a rendering pipe on an Intel Baytrail 
E3845 cpu.
In our product we want to have an FPGA streaming video images to a 
predefined memory area using bus master dma and render those images 
using OpenGL. So far this works in a preliminary state.
We now have the security requirement that in case the CPU 
(software/kernel driver) crashes for what ever reason, the GPU display 
signal should still output at least the video images (obviously any 
additional render stuff will not be available anymore). My question is 
now, would it be possible to get the physical address of the DRM front 
buffer, so that I can provide this address to the FPGA (connected via 
PCIe) and is it possible to have the GPU still reading the last front 
buffer for the display output while the FPGA writes to that area. So I 
would think that the GPU has some kind of DMA engine running, that 
continuously reading the last front buffer until switched to another 
buffer by the CPU. So even if the CPU does not control the GPU anymore, 
it might be possible to have the front buffer updated by the FPGA 
directly. Of course there will be tearing artefacts as no VSYNC will be 
available but that wouldn't be an issue so far.

Kind regards,
 Volker