linux-kernel - Re: DRM DMA Engine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKMK7uGbqKbTdb1UAEdEQPkLeiuStSqpC3CtNoyQmjY8-6i=+w@mail.gmail.com>
Date:	Wed, 15 Jun 2016 12:15:30 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Jose Abreu <Jose.Abreu@...opsys.com>
Cc:	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Subject: Re: DRM DMA Engine

On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu <Jose.Abreu@...opsys.com> wrote:
>
> On 15-06-2016 09:52, Daniel Vetter wrote:
>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu <Jose.Abreu@...opsys.com> wrote:
>>>> I assume that xilinx VDMA is the only way to feed pixel data into your
>>>> display pipeline. Under that assumption:
>>>>
>>>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
>>>> would represent the dma channel. With atomic you can subclass
>>>> drm_plane/crtc_state structures to store all the runtime configuration in
>>>> there.
>>>>
>>>> The actual buffer itsel would be represented by a drm_framebuffer, which
>>>> either wraps a shmem gem or a cma gem object.
>>>>
>>>> If you want to know about the callbacks used by the atomic helpers to push
>>>> out plane updates, look at the hooks drm_atomic_helper_commit_planes()
>>>> (and the related functions, see kerneldoc) calls.
>>>>
>>>> I hope this helps a bit more.
>>>> -Daniel
>>> Thanks a lot! With your help I was able to implement all the
>>> needed logic. Sorry to bother you but I have one more question.
>>> Right now I can initialize and configure the vdma correctly but I
>>> can only send one frame. I guess when the dma completes
>>> transmission I need to ask drm for a new frame, right? Because
>>> the commit function starts the vdma correctly but then the dma
>>> halts waiting for a new descriptor.
>> DRM has a continuous scanout model, i.e. when userspace doesn't give
>> you a new frame you're supposed to keep scanning out the current one.
>> So you need to rearm your upload code with the same drm_framebuffer if
>> userspace hasn't supplied a new one since the last time before the
>> vblank period starts.
>>
>> This is different to v4l, where userspace has to supply each frame
>> (and the kernel gets angry when there's not enough frames and signals
>> an underrun of the queue). This is because drm is geared at desktops,
>> and there it's perfectly normal to show the exact same frame for a
>> long time.
>> -Daniel
>
> Thanks, I was thinking this was similar to v4l. I am now able to
> send multiple frames so it is finally working! I have one little
> implementation detail: The controller that I am using supports
> deep color mode but I am using FB CMA helpers to create the
> framebuffer and I've seen that the supported bpp in these helpers
> only goes up to 32, right? Does this means that with these
> helpers I can't use deep color? Can I implement this deep color
> mode (48bpp) using a custom fb or do I also need custom gem
> allocation functions (Right now I am using GEM CMA helpers)?

Suprising the cma doesn't take pixel_format into account. If this
really doesn't work, pls fix up the cma helpers, not roll your own
copypasta ;-)

Note that the fbdev emulation itself (maybe that's what threw you off)
only supports legacy rgb formats up to 32bits. But native kms can
support anything, we just might need to add the DRM_FOURCC codes for
that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch