All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Jones <michael.jones@matrix-vision.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH] Documentation: DocBook DRM framework documentation
Date: Mon, 23 Jul 2012 17:12:43 +0200	[thread overview]
Message-ID: <500D69EB.6000008@matrix-vision.de> (raw)
In-Reply-To: <1342137623-7628-1-git-send-email-laurent.pinchart@ideasonboard.com>

Hi Laurent,

At a quick glance I noticed a couple of things:

On 07/13/2012 02:00 AM, Laurent Pinchart wrote:

[snip]

> +    <para>
> +      The <structname>drm_driver</structname> structure contains static
> +      information that describe the driver and features it supports, and

s/describe/describes/

> +      pointers to methods that the DRM core will call to implement the DRM API.
> +      We will first go through the <structname>drm_driver</structname> static
> +      information fields, and will then describe individual operations in
> +      details as they get used in later sections.
>       </para>
> -
>       <sect2>
> -      <title>Driver private &amp; performance counters</title>
> -      <para>
> -	The driver private hangs off the main drm_device structure and
> -	can be used for tracking various device-specific bits of
> -	information, like register offsets, command buffer status,
> -	register state for suspend/resume, etc.  At load time, a
> -	driver may simply allocate one and set drm_device.dev_priv
> -	appropriately; it should be freed and drm_device.dev_priv set
> -	to NULL when the driver is unloaded.
> -      </para>
> +      <title>Driver Information</title>
> +      <sect3>
> +        <title>Driver Features</title>
> +        <para>
> +          Drivers inform the DRM core about their requirements and supported
> +          features by setting appropriate flags in the
> +          <structfield>driver_features</structfield> field. Since those flags
> +          influence the DRM core behaviour since registration time, most of them

Elsewhere you use the American spelling "behavior".

[snip]

> +      <sect3>
> +        <title>Major, Minor and Patchlevel</title>
> +        <synopsis>int major;
> +  int minor;
> +  int patchlevel;</synopsis>

In my browser, "int minor" and "int patchlevel" look indented, whereas 
"int major" does not.  Looks like they _should_ be indented identically. 
Don't know how you fix this or if you even see the same problem.

> +        <para>
> +          The DRM core identifies driver versions by a major, minor and patch
> +          level triplet. The information is printed to the kernel log at
> +          initialization time and passed to userspace through the
> +          DRM_IOCTL_VERSION ioctl.
> +        </para>
> +        <para>
> +          The major and minor numbers are also used to verify the requested driver
> +          API version passed to DRM_IOCTL_SET_VERSION. When the driver API changes
> +          between minor versions, applications can call DRM_IOCTL_SET_VERSION to
> +          select a specific version of the API. If the requested major isn't equal
> +          to the driver major, or the requested minor is larger than the driver
> +          minor, the DRM_IOCTL_SET_VERSION call will return an error. Otherwise
> +          the driver's set_version() method will be called with the requested
> +          version.
> +        </para>
> +      </sect3>
> +      <sect3>
> +        <title>Name, Description and Date</title>
> +        <synopsis>char *name;
> +  char *desc;
> +  char *date;</synopsis>

Same indentation issue here.

[snip]

> +          <para>
> +            The <methodname>mode_fixup</methodname> operation should reject the
> +            mode if it can't reasonably use it. The definition of "reasonable"
> +            is currently fuzzy in this context. One possible behaviour would be

maybe s/behaviour/behavior/ again



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier

  parent reply	other threads:[~2012-07-23 15:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13  0:00 [PATCH] Documentation: DocBook DRM framework documentation Laurent Pinchart
2012-07-16 18:32 ` Rob Clark
2012-07-17 11:20 ` Laurent Pinchart
2012-07-23 15:12 ` Michael Jones [this message]
2012-07-23 17:12   ` Laurent Pinchart
2012-07-24  6:42     ` Michael Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500D69EB.6000008@matrix-vision.de \
    --to=michael.jones@matrix-vision.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.