Message-ID: <20140514172255.GA8122@kroah.com>
Date:	Wed, 14 May 2014 10:22:55 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Thierry Reding <thierry.reding@...il.com>,
	Russell King <rmk+kernel@....linux.org.uk>,
	dri-devel@...ts.freedesktop.org, Rob Clark <robdclark@...il.com>,
	David Herrmann <dh.herrmann@...il.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/7] drivers/base: Add interface framework

On Wed, May 14, 2014 at 04:37:19PM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote:
> > 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@...dia.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@...dia.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...
> 
> Hm, I've victimized^Wvolunteered a few internal people to look into a
> hdmi/dp sink bus type of thing so that we can move away from all those
> ad-hoc hacks currently used to coordinate between drm display drivers and
> the audio side of things. So I'm interested.
> 
> Do you have some ideas somewhere already about how you think this should
> look like? Or is this more a "hey, this would be really cool, eventually"
> kind of thing?

It was very much a "hey, this would be really cool" type of thing,
nothing specific at all, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists