All of lore.kernel.org
 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>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	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: Mon, 3 Nov 2014 09:01:58 +0100	[thread overview]
Message-ID: <20141103080155.GA21002@ulmo.nvidia.com> (raw)
In-Reply-To: <20141031155143.GQ26941@phenom.ffwll.local>


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

On Fri, Oct 31, 2014 at 04:51:43PM +0100, Daniel Vetter wrote:
> On Wed, Oct 29, 2014 at 10:14:37AM +0100, Thierry Reding wrote:
> > On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
> > > That makes the entire thing a bit non-trivial, which is why I think it
> > > would be better as some generic helper. Which then gets embedded or
> > > instantiated for specific cases, like dt&drm_panel or dt&drm_bridge.
> > > Or maybe even acpi&drm_bridge, who knows ;-)
> > 
> > I worry a little about type safety. How will this generic helper know
> > what registry to look in for? Or conversely, if all these resources are
> > added to a single registry how do you know that they're of the correct
> > type? Failing to ensure this could cause situations where you're asking
> > for a panel and get a bridge in return because you've wrongly wired it
> > up in device tree for example.
> > 
> > But perhaps if both the registry and the device parts are turned into
> > helpers we could still have a single core implementation and then
> > instantiate that for each type, something roughly like this:
> > 
> > 	struct registry {
> > 		struct list_head list;
> > 		struct mutex lock;
> > 	};
> > 
> > 	struct registry_record {
> > 		struct list_head list;
> > 		struct module *owner;
> > 		struct kref *ref;
> > 
> > 		struct device *dev;
> > 	};
> > 
> > 	int registry_add(struct registry *registry, struct registry_record *record)
> > 	{
> > 		...
> > 		try_module_get(record->owner);
> > 		...
> > 	}
> > 
> > 	struct registry_record *registry_find_by_of_node(struct registry *registry,
> > 							 struct device_node *np)
> > 	{
> > 		...
> > 		kref_get(...);
> > 		...
> > 	}
> > 
> > That way it should be possible to embed these into other structures,
> > like so:
> > 
> > 	struct drm_panel {
> > 		struct registry_record record;
> > 		...
> > 	};
> > 
> > 	static struct registry drm_panels;
> > 
> > 	int drm_panel_add(struct drm_panel *panel)
> > 	{
> > 		return registry_add(&drm_panels, &panel->record);
> > 	}
> > 
> > 	struct drm_panel *of_drm_panel_find(struct device_node *np)
> > 	{
> > 		struct registry_record *record;
> > 
> > 		record = registry_find_by_of_node(&drm_panels, np);
> > 
> > 		return container_of(record, struct drm_panel, record);
> > 	}
> > 
> > Is that what you had in mind?
> 
> Yeah I've thought that we should instantiate using macros even, so that we
> have per-type registries. So you'd smash the usual set of
> DECLARE/DEFINE_AUX_DEV_REGISTRY into headers/source files, and they'd take
> a (name, key, value) tripled. For the example here(of_drm_panel, struct
> device_node *, struct drm_panel *) or similar. I might be hand-waving over
> a few too many details though ;-)

Okay, I'll take a stab at this and see if I can convert DRM panel to it.

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

  reply	other threads:[~2014-11-03  8:01 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 [this message]
2014-11-03  8:26                         ` Ajay kumar
2014-10-28 14:29         ` Thierry Reding
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=20141103080155.GA21002@ulmo.nvidia.com \
    --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=linux@arm.linux.org.uk \
    --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 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.