From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
linux-doc@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Rob Landley <rob@landley.net>,
David Herrmann <dh.herrmann@gmail.com>,
Alex Deucher <alexander.deucher@amd.com>,
Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
Date: Wed, 12 Mar 2014 12:25:06 +0100 [thread overview]
Message-ID: <3136468.2PAlK4Gq8k@avalon> (raw)
In-Reply-To: <1394622965.18918.12.camel@sagar-desktop>
Hi Sagar,
On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote:
> On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote:
> > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote:
> > > On Wed, Mar 5, 2014 at 11:56 AM, <sagar.a.kamble@intel.com> wrote:
> > > > +<table border="1" cellpadding="0" cellspacing="0" >
> > > > +<tbody>
> > > > +<tr style="font-weight: bold;" >
> > > > +<td valign="top" >Owner Module/Drivers</td>
> > > > +<td valign="top" >Group</td>
> > > > +<td valign="top" >Property Object</td>
> > > > +<td valign="top" >Property Name</td>
> > > > +<td valign="top" >Type</td>
> > > > +<td valign="top" >Property Values</td>
> > > > +<td valign="top" >Object attached</td>
> > > > +<td valign="top" >Description</td>
> > > > +</tr>
> > >
> > > In my opinion this is a horrible way to write property documentations
> > > - explicitly constructing html tables is error prone and really hard
> > > to read in the source. Imo docbook in general is rather horrible,
> > > which is way I write almost all my docs as kerneldoc ;-)
> > >
> > > I think a simple asciidoc/markdown would be much simpler, with a bit
> > > of free-form structure to group properties into relevant groups.
> > > Long-term we might even need to split it up into different spec files
> > > to keep a good overview.
> >
> > Docbook is indeed hard to read and write when it comes to such tables.
> > However I like having the properties documented in the DRM core
> > documentation. Maybe we could come up with a simpler text format that
> > would be transformed into docbook when compiling the documentation ?
>
> Does this mean we need to create comment block with "Doc: drm
> properties" style section in each driver where drm properties are
> instantiated. And then in drm.tmpl collect all these using !P escape
> sequence?
> How do create table out of these across all drivers?
I don't have a strong preference here. Documenting properties in source code
comments would be fine, so would an external central documentation file in a
non Docbook format. For the record I'm personally fine with using Docbook as
in this patch :-)
If we decide to go for property documentation inside the source code then I
believe we'll have to create our own format, as creating a properties table
from kerneldoc information extracted from comments is probably not possible.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-03-12 11:23 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 10:56 [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers sagar.a.kamble
2014-03-06 7:15 ` [PATCH v2 " sagar.a.kamble
2014-03-06 12:09 ` Ville Syrjälä
2014-03-06 14:01 ` Sagar Arun Kamble
2014-03-06 14:27 ` [PATCH v3 " sagar.a.kamble
2014-03-07 18:44 ` Randy Dunlap
2014-03-08 6:33 ` [PATCH v4 " sagar.a.kamble
2014-03-08 7:28 ` [PATCH v5 " sagar.a.kamble
2014-03-10 14:33 ` Laurent Pinchart
2014-03-11 10:37 ` [PATCH v6 " sagar.a.kamble
2014-03-11 11:22 ` Laurent Pinchart
2014-03-11 14:25 ` [PATCH v7 " sagar.a.kamble
2014-03-11 14:31 ` Laurent Pinchart
2014-03-11 13:13 ` [PATCH v6 " Deucher, Alexander
2014-03-11 14:07 ` Sagar Arun Kamble
2014-03-06 14:41 ` [PATCH v3 " sagar.a.kamble
2014-03-10 5:21 ` [PATCH " Daniel Vetter
2014-03-10 14:36 ` Laurent Pinchart
2014-03-12 11:16 ` Sagar Arun Kamble
2014-03-12 11:25 ` Laurent Pinchart [this message]
2014-05-10 10:39 ` Ville Syrjälä
2014-05-10 10:56 ` Rob Clark
2014-05-12 6:07 ` Sagar Arun Kamble
2014-05-12 8:03 ` Daniel Vetter
2014-05-13 7:17 ` Thierry Reding
2014-05-13 7:34 ` Daniel Vetter
2014-05-13 9:05 ` Thierry Reding
2014-05-13 11:02 ` Laurent Pinchart
2014-05-13 11:51 ` Daniel Vetter
2014-05-12 8:24 ` Dave Airlie
2014-05-12 8:58 ` Daniel Vetter
2014-05-12 15:23 ` Randy Dunlap
2014-05-12 15:54 ` Daniel Vetter
2014-05-12 18:04 ` Randy Dunlap
2014-07-31 22:16 ` Randy Dunlap
2014-08-01 12:58 ` Laurent Pinchart
2014-08-01 22:21 ` Randy Dunlap
2014-08-04 7:30 ` Daniel Vetter
2014-08-04 13:58 ` Laurent Pinchart
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=3136468.2PAlK4Gq8k@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dh.herrmann@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=rob@landley.net \
--cc=sagar.a.kamble@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox