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 a > pointer > to DRM frame buffer operations (struct > <structname>drm_framebuffer_funcs</structname>). Note that this > function > > -- > Regards, > > Laurent Pinchart > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
