On Fri, Jan 24, 2014 at 12:08:36PM +0100, Laurent Pinchart wrote:
Hi Daniel,
On Thursday 23 January 2014 14:46:40 Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 01:56:51PM +0100, Laurent Pinchart wrote:
<para> Drivers must first validate the requested frame buffer parameters passed@@ -1052,6 +998,71 @@ int max_width, max_height;</synopsis>
<function>drm_framebuffer_unregister_private</function>.
</sect2> <sect2>
<title>Dumb GEM Objects</title><para>- The KMS API doesn't standardize backing storage object creation
and
Strictly speaking isn't it the DRM API that's responsible for memory management, not the KMS API ?
The driver's private api is responsible for memory management, but the crucial thing here is that the KMS ioctls don't mandate anything specific (beyong that it needs to use uint32_t for handles).
Sure, but my point was that I believe memory management is the responsibility of DRM, not KMS. It of course needs to be driver-specific.
Well imo the dumb ioctls are part of kms. DRM itself doesn't have any memory management interfaces (at least if you ignore all the horror stories around legacy ums/dri1 drivers). My reasons are:
- If you implement a kms driver you really should implement the dumb interfaces. Even when you have almost no memory management like the simpledrm driver.
- If you have a driver with memory management and command submission but no KMS, there's no reason at all to implement the dumb interfaces.
- ARM people abused dumb buffers for accelaration "because it worked", so imo moving it's documentation as far away as possible from the memory management section is a feature.
So the dumb stuff is a KMS interface to abstract away the lowest common denominator between all kms drivers. Actually memory manament needs a real interface, and is obviously separate.
OK. Those ioctls are not available on render nodes, which I suppose is another sign that they're KMS ioctls.
What about the device-specific memory allocation ioctls though ? Are they considered part of DRM or KMS ?
DRM is everything, so I'd add it to the driver-specific GEM section of the documentation. Like I've said in another mail in this thread, there's some room in the GEM docs to untangle core interfaces from driver-specific interfaces (but often done in a similar way as established best practice). But right now I'm mostly going through the modesetting stuff, also since that's the part I want to start with for i915.
[snip]
BTW, while you're at it, could you squash this typo fix in ?
Applied, thanks for spotting this typo. -Daniel
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ed1d6d2..1e6579f 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -992,7 +992,7 @@ int max_width, max_height;</synopsis> </para>
<para>
The initailization of the new framebuffer instance is finalized with a
The initialization of the new framebuffer instance is finalized with a call to <function>drm_framebuffer_init</function> which takes apointer to DRM frame buffer operations (struct <structname>drm_framebuffer_funcs</structname>). Note that this function
-- Regards,
Laurent Pinchart