From: Daniel Vetter <daniel@ffwll.ch>
To: Dave Airlie <airlied@gmail.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"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>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com>,
"Rob Landley" <rob@landley.net>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Dave Airlie" <airlied@redhat.com>,
"Sagar Arun Kamble" <sagar.a.kamble@intel.com>
Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
Date: Mon, 12 May 2014 10:58:27 +0200 [thread overview]
Message-ID: <20140512085827.GD25056@phenom.ffwll.local> (raw)
In-Reply-To: <CAPM=9ty6vj384am4Hfw1idOP6sHXJ4y0X2ty0CdkfxcmvGf4sw@mail.gmail.com>
On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
> >>
> >> 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.
> >
> > Can comeone pick up the ball here and figure out what needs to be done?
> >
> > The reason why I want a central place for the documentation is to force
> > people to collaborate outside their own sandbox when adding properties.
> > Whether that's docbook or some text file I don't care so much at this
> > point. The fact that it's a central place should mandate that the
> > patches changing it will go through dri-devel and so everyone should se
> > them, and when adding new properties it would make the patch author more
> > likely to look around a bit before adding another slighty incompatible
> > version of the same property. If someone has a better suggestion how to
> > encforce this I'm all ears.
> >
> > Of course this idea can still fail if our esteemed maintainer merges
> > stuff without checking for violations of this policy. Dave, any thoughts
> > on the subject?
>
> Yeah I'm happy to block merging stuff, if we can spot new properties
> when stuff is posted on dri-devel, so much the better,
>
> most drivers still send everything via dri-devel anyways, its only
> really Intel I have to worry about so far,
I'll enforce that all prop stuff gets cc: dri-devel and that it has
updates for the prop docs.
> But we should definitely add it to the new driver review checklist as well.
>
> I'm also on the side of this patch is ugly and makes my eyes burn,
> please please get a plan to use something else ASAP, I'm willing to
> merge this but I'm tempted to give it a lifetime of a kernel or two
> before I burn it.
Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
find someone to do it for me internally ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-05-12 8:58 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
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 [this message]
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=20140512085827.GD25056@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=rob@landley.net \
--cc=sagar.a.kamble@intel.com \
--cc=vijay.a.purushothaman@intel.com \
--cc=ville.syrjala@linux.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 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.