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
next prev 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).