Re: [PATCH 01/19] drm/doc: Clarify the dumb object interfaces

[Daniel Vetter <daniel@ffwll.ch>]

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