linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thierry Reding <thierry.reding@gmail.com>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	dri-devel@lists.freedesktop.org, Rob Clark <robdclark@gmail.com>,
	David Herrmann <dh.herrmann@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/7] drivers/base: Add interface framework
Date: Tue, 13 May 2014 17:32:15 -0700	[thread overview]
Message-ID: <20140514003215.GA21520@kroah.com> (raw)
In-Reply-To: <20140513175713.GS3908@phenom.ffwll.local>

On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > Some drivers, such as graphics drivers in the DRM subsystem, do not have
> > a real device that they can bind to. They are often composed of several
> > devices, each having their own driver. The master/component framework
> > can be used in these situations to collect the devices pertaining to one
> > logical device, wait until all of them have registered and then bind
> > them all at once.
> > 
> > For some situations this is only a partial solution. An implementation
> > of a master still needs to be registered with the system somehow. Many
> > drivers currently resort to creating a dummy device that a driver can
> > bind to and register the master against. This is problematic since it
> > requires (and presumes) knowledge about the system within drivers.
> > 
> > Furthermore there are setups where a suitable device already exists, but
> > is already bound to a driver. For example, on Tegra the following device
> > tree extract (simplified) represents the host1x device along with child
> > devices:
> > 
> > 	host1x {
> > 		display-controller {
> > 			...
> > 		};
> > 
> > 		display-controller {
> > 			...
> > 		};
> > 
> > 		hdmi {
> > 			...
> > 		};
> > 
> > 		dsi {
> > 			...
> > 		};
> > 
> > 		csi {
> > 			...
> > 		};
> > 
> > 		video-input {
> > 			...
> > 		};
> > 	};
> > 
> > Each of the child devices is in turn a client of host1x, in that it can
> > request resources (command stream DMA channels and syncpoints) from it.
> > To implement the DMA channel and syncpoint infrastructure, host1x comes
> > with its own driver. Children are implemented in separate drivers. In
> > Linux this set of devices would be exposed by DRM and V4L2 drivers.
> > 
> > However, neither the DRM nor the V4L2 drivers have a single device that
> > they can bind to. The DRM device is composed of the display controllers
> > and the various output devices, whereas the V4L2 device is composed of
> > one or more video input devices.
> > 
> > This patch introduces the concept of an interface and drivers that can
> > bind to a given interface. An interface can be exposed by any device,
> > and interface drivers can bind to these interfaces. Multiple drivers can
> > bind against a single interface. When a device is removed, interfaces
> > exposed by it will be removed as well, thereby removing the drivers that
> > were bound to those interfaces.
> > 
> > In the example above, the host1x device would expose the "tegra-host1x"
> > interface. DRM and V4L2 drivers can then bind to that interface and
> > instantiate the respective subsystem objects from there.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > Note that I'd like to merge this through the Tegra DRM tree so that the
> > changes to the Tegra DRM driver later in this series can be merged at
> > the same time and are not delayed for another release cycle.
> > 
> > In particular that means that I'm looking for an Acked-by from Greg.
> > 
> >  drivers/base/Makefile     |   2 +-
> >  drivers/base/interface.c  | 186 ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/interface.h |  40 ++++++++++
> >  3 files changed, 227 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/base/interface.c
> >  create mode 100644 include/linux/interface.h
> 
> Hm, this interface stuff smells like bus drivers light. Should we instead
> have a pile of helpers to make creating new buses with match methods more
> trivial? There's a fairly big pile of small use-cases where this might be
> useful. In your case here all the host1x children would sit on a host1x
> bus. Admittedly I didn't look into the details.

I have no problem adding such "bus-light" functions, to make it easier
to create and implement a bus in the driver core, as I know it's really
heavy.  That's been on my "todo" list for over a decade now...

thanks,

greg k-h

  parent reply	other threads:[~2014-05-14  0:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 15:30 [PATCH v2 0/7] drm/tegra: Convert to master/component framework Thierry Reding
2014-05-13 15:30 ` [PATCH v2 1/7] drm: Introduce drm_set_unique() Thierry Reding
2014-05-13 15:46   ` David Herrmann
2014-05-13 15:30 ` [PATCH v2 2/7] drivers/base: Allow driver-data to be attached to a master Thierry Reding
2014-05-13 15:30 ` [PATCH v2 3/7] drivers/base: Allow multiple masters per device Thierry Reding
2014-05-13 15:30 ` [PATCH v2 4/7] drivers/base: Add interface framework Thierry Reding
2014-05-13 17:57   ` Daniel Vetter
     [not found]     ` <20140513175713.GS3908-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2014-05-13 21:31       ` Thierry Reding
2014-05-14 14:34         ` Daniel Vetter
2014-05-14 15:13           ` Thierry Reding
2014-05-14  0:32     ` Greg Kroah-Hartman [this message]
2014-05-14 14:37       ` Daniel Vetter
2014-05-14 17:22         ` Greg Kroah-Hartman
     [not found]       ` <20140514003215.GA21520-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-05-15  8:53         ` Thierry Reding
2014-05-20  9:27           ` Andrzej Hajda
2014-05-13 15:30 ` [PATCH v2 5/7] drm/tegra: Convert to master/component framework Thierry Reding
     [not found]   ` <1399995050-28435-6-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-19  8:56     ` Christian Gmeiner
2014-05-19 15:25       ` Thierry Reding
2014-05-13 15:30 ` [PATCH v2 6/7] drm: Add device registration documentation Thierry Reding
2014-05-13 17:59   ` Daniel Vetter
2014-05-13 15:30 ` [PATCH v2 7/7] drm: Document how to register devices without struct drm_bus Thierry Reding
2014-05-13 15:55   ` David Herrmann
2014-05-22  9:56 ` [PATCH v2 0/7] drm/tegra: Convert to master/component framework Thierry Reding
2014-05-23 11:03   ` Greg Kroah-Hartman
2014-05-25 11:45     ` 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=20140514003215.GA21520@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=robdclark@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=thierry.reding@gmail.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).