From: Daniel Vetter <daniel@ffwll.ch>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 7/9] drm: Extract drm_property.[hc]
Date: Thu, 18 Aug 2016 15:11:50 +0200 [thread overview]
Message-ID: <20160818131150.GC6232@phenom.ffwll.local> (raw)
In-Reply-To: <CACvgo53f5KWWW=3rzFCWwVaAWgRJSKGn4E6qWy-NUn4tKVfGpw@mail.gmail.com>
On Thu, Aug 18, 2016 at 12:11:35PM +0100, Emil Velikov wrote:
> Hi Daniel,
>
> On 17 August 2016 at 21:56, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > --- /dev/null
> > +++ b/include/drm/drm_property.h
>
> > +#ifndef __DRM_PROPERTY_H__
> > +#define __DRM_PROPERTY_H__
> > +
> > +#include <linux/list.h>
> > +#include <linux/ctype.h>
> > +#include <drm/drm_mode_object.h>
> > +
> Add the following fwd declaration since we use a pointer to the said
> struct ? From a brief look the other newly introduced headers
> could/should use it as well.
>
> struct drm_device;
tbh this is only a half-useful attempt at untangling the header loop mess.
Once drm_crtc.[hc] is fully split I guess we can look into what makes
sense. I'll definitely be happy to review patches, but personally I don't
mind loops in headers much. It's annoying, but as long as things are
reasonably split and it's possible to untangle at least the
code/structures and documentation itself I'm happy.
Wrt all things drm_device: I'm not sure when (if ever) I'll cough up the
courage to split up and untangle drmP.h ;-)
> The declarations in include/drm should be the ones meant for drivers
> and there's no core drm internal ones ? Where/how does one manage API
> that should be kept private between the different core DRM components,
> even if there's symbol dependency between the different modules ?
drm_crtc_helper_internal.h, drm_crtc_internal.h and drm_internal.h, all in
drivers/gpu/drm/
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-08-18 13:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 20:55 [PATCH 1/9] drm: Extract drm_encoder.[hc] Daniel Vetter
2016-08-17 20:55 ` [PATCH 2/9] drm/doc: Polish kerneldoc for encoders Daniel Vetter
2016-08-25 12:24 ` Archit Taneja
2016-08-17 20:56 ` [PATCH 3/9] drm: Extract drm_mode_object.[hc] Daniel Vetter
2016-08-25 12:25 ` Archit Taneja
2016-08-25 19:40 ` Daniel Vetter
2016-08-26 3:16 ` Archit Taneja
2016-08-17 20:56 ` [PATCH 4/9] drm: Remove drm_mode_object->atomic_count Daniel Vetter
2016-08-25 12:25 ` Archit Taneja
2016-08-17 20:56 ` [PATCH 5/9] drm/doc: Polish docs for drm_mode_object Daniel Vetter
2016-08-25 12:25 ` Archit Taneja
2016-08-17 20:56 ` [PATCH 6/9] drm: move drm_mode_legacy_fb_format to drm_fourcc.c Daniel Vetter
2016-08-25 12:25 ` Archit Taneja
2016-08-17 20:56 ` [PATCH 7/9] drm: Extract drm_property.[hc] Daniel Vetter
2016-08-18 11:11 ` Emil Velikov
2016-08-18 13:11 ` Daniel Vetter [this message]
2016-08-25 12:25 ` Archit Taneja
2016-08-17 20:56 ` [PATCH 8/9] drm: Unify handling of blob and object properties Daniel Vetter
2016-08-25 12:26 ` Archit Taneja
2016-08-17 20:56 ` [PATCH 9/9] drm/doc: Polish docs for drm_property&drm_property_blob Daniel Vetter
2016-08-18 7:39 ` ✗ Ro.CI.BAT: failure for series starting with [1/9] drm: Extract drm_encoder.[hc] Patchwork
2016-08-25 12:23 ` [PATCH 1/9] " Archit Taneja
2016-08-25 19:38 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2016-08-29 8:27 Daniel Vetter
2016-08-29 8:27 ` [PATCH 7/9] drm: Extract drm_property.[hc] Daniel Vetter
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=20160818131150.GC6232@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=intel-gfx@lists.freedesktop.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.