dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	Jingoo Han <jg1.han@samsung.com>, sunil joshi <joshi@samsung.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Ajay kumar <ajaynumb@gmail.com>,
	Thierry Reding <treding@nvidia.com>,
	Prashanth G <prashanth.g@samsung.com>,
	Ajay Kumar <ajaykumar.rs@samsung.com>
Subject: Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
Date: Tue, 28 Oct 2014 15:29:47 +0100	[thread overview]
Message-ID: <20141028142946.GA17770@ulmo> (raw)
In-Reply-To: <CAKMK7uEch65=ZuaG=4JY2u3S3w5RND+uNc5+qL=tWxDLfEqEwQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1891 bytes --]

On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul <seanpaul@chromium.org> wrote:
> >>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> >>>   * @driver_private: pointer to the bridge driver's internal context
> >>>   */
> >>>  struct drm_bridge {
> >>> -     struct drm_device *dev;
> >>> +     struct device *dev;
> >>
> >> Please don't rename the ->dev pointer into drm. Because _all_ the other
> >> drm structures still call it ->dev. Also, can't we use struct device_node
> >> here like we do in the of helpers Russell added? See 7e435aad38083
> >>
> >
> > I think this is modeled after the naming in drm_panel, FWIW. However,
> > seems reasonable to keep the device_node instead.
> 
> Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> drm_crtc drop the struct device and go directly to a struct
> device_node. Since we don't really need the sturct device, the only
> thing we care about is the of_node. For added bonus wrap an #ifdef
> CONFIG_OF around all the various struct device_node in drm_foo.h.
> Should be all fairly simple to pull off with cocci.
> 
> Thierry?

The struct device * is in DRM panel because there's nothing device tree
specific about the concept. Having a struct device_node * instead would
indicate that it can only be used with a device tree, whereas the
framework doesn't care the tiniest bit what type of device we have.

While the trend clearly is to use more device tree, I don't think we
should make it impossible for anybody else to use these frameworks.

There are other advantages to keeping a struct device *, like having
access to the proper device and its name. Also you get access to the
device_node * via dev->of_node anyway. I don't see any advantage in
switching to just a struct device_node *, only disadvantages.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2014-10-28 14:29 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 14:29 [PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
2014-08-27 14:29 ` [PATCH V7 01/12] drm/bridge: ptn3460: Few trivial cleanups Ajay Kumar
2014-08-27 14:29 ` [PATCH V7 02/12] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init Ajay Kumar
2014-10-27 19:50   ` Sean Paul
2014-08-27 14:29 ` [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge Ajay Kumar
2014-10-27 19:01   ` Daniel Vetter
2014-10-27 19:58     ` Sean Paul
2014-10-27 22:20       ` Daniel Vetter
2014-10-27 22:26         ` Daniel Vetter
2014-10-27 23:57           ` Russell King - ARM Linux
2014-11-04  9:22             ` Philipp Zabel
2014-10-28 14:35           ` Thierry Reding
2014-10-29  7:43             ` Daniel Vetter
2014-10-29  8:38               ` Thierry Reding
2014-10-29  8:57                 ` Daniel Vetter
2014-10-29  9:14                   ` Thierry Reding
2014-10-30 10:01                     ` Andrzej Hajda
2014-10-30 10:09                       ` Russell King - ARM Linux
2014-10-31 15:54                         ` Daniel Vetter
2014-10-31 15:51                     ` Daniel Vetter
2014-11-03  8:01                       ` Thierry Reding
2014-11-03  8:26                         ` Ajay kumar
2014-10-28 14:29         ` Thierry Reding [this message]
2014-10-29  7:51           ` Daniel Vetter
2014-10-29  9:16             ` Thierry Reding
2014-10-31 15:59               ` Daniel Vetter
2014-11-03  8:06                 ` Thierry Reding
2014-11-03  8:11                   ` Daniel Vetter
2014-10-28  9:21       ` Ajay kumar
2014-10-28 10:01         ` Daniel Vetter
2014-10-28 12:28           ` Ajay kumar
2014-10-28 14:19             ` Daniel Vetter
2014-10-28 14:28               ` Sean Paul
2014-10-28 14:41               ` Thierry Reding
2014-10-28 14:46                 ` Ajay kumar
2014-10-28 15:05                   ` Thierry Reding
2014-10-29  7:58                     ` Daniel Vetter
2014-10-29  9:09                       ` Andrzej Hajda
2014-10-31 16:03                         ` Daniel Vetter
2014-10-27 20:11   ` Sean Paul
2014-10-28  9:22     ` Ajay kumar
2014-10-28  9:26     ` Ajay kumar
2014-08-27 14:29 ` [PATCH V7 04/12] drm/bridge: ptn3460: Convert to i2c driver model Ajay Kumar
2014-08-27 14:29 ` [PATCH V7 05/12] drm/exynos: dp: support drm_bridge Ajay Kumar
2014-08-27 14:29 ` [PATCH V7 06/12] drm/bridge: ptn3460: support drm_panel Ajay Kumar
2014-08-27 14:29 ` [PATCH V7 07/12] drm/bridge: ptn3460: probe connector at the end of bridge attach Ajay Kumar
2014-08-27 14:29 ` [PATCH V7 08/12] drm/bridge: ptn3460: use gpiod interface Ajay Kumar
2014-08-27 14:29 ` [PATCH V7 12/12] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge Ajay Kumar
2014-09-10 13:18 ` [PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support Ajay kumar
2014-09-16 12:44 ` Javier Martinez Canillas
2014-09-16 20:11   ` Laurent Pinchart
2014-09-17  9:32   ` Ajay kumar
2014-09-20 11:27     ` Ajay kumar
2014-09-22 10:18     ` Thierry Reding

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=20141028142946.GA17770@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=ajaykumar.rs@samsung.com \
    --cc=ajaynumb@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jg1.han@samsung.com \
    --cc=joshi@samsung.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=prashanth.g@samsung.com \
    --cc=treding@nvidia.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;
as well as URLs for NNTP newsgroup(s).