On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote:
> On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
> > (BTW each driver in drm has this layer somewhere in it. If I had hidden
> > it in imx specific functions I probably wouldn't have raised any
> > questions, but I don't
On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote:
On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
(BTW each driver in drm has this layer somewhere in it. If I had hidden
it in imx specific functions I probably wouldn't have raised any
questions, but I don't want
On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:
> On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> > * Dave Airlie wrote:
> > > I get the feeling the drm can just be a virtual platform device of
> > > some sort, then it reads the device tree and binds all the
* Mark Brown wrote:
> On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
> > * Mark Brown wrote:
>
> > > This sounds an awful lot like how ASoC hangs together...
>
> > What in particular sounds awful?
>
> Nothing - "an awful" is an English idiom for "very".
I know =) But it has a
* Mark Brown wrote:
> On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> > * Dave Airlie wrote:
> > > I get the feeling the drm can just be a virtual platform device of
> > > some sort, then it reads the device tree and binds all the information
> > > on what crtc/encoders are
On Fri, Apr 20, 2012 at 05:15:18PM +0200, Sascha Hauer wrote:
> On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:
> > This sounds an awful lot like how ASoC hangs together...
> Very much, yes. In ASoC and DRM we both have several physical devices spread
> around the SoC which form a
On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
> * Mark Brown wrote:
> > This sounds an awful lot like how ASoC hangs together...
> What in particular sounds awful?
Nothing - "an awful" is an English idiom for "very".
-- next part --
A non-text
On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
> (BTW each driver in drm has this layer somewhere in it. If I had hidden
> it in imx specific functions I probably wouldn't have raised any
> questions, but I don't want to go that way)
That's _exactly_ what you should be doing. And
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> * Dave Airlie wrote:
> > I get the feeling the drm can just be a virtual platform device of
> > some sort, then it reads the device tree and binds all the information
> > on what crtc/encoders are available,
> That's pretty much
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> * Dave Airlie wrote:
> > I get the feeling the drm can just be a virtual platform device of
> > some sort, then it reads the device tree and binds all the information
> > on what crtc/encoders are available,
>
> That's pretty much
[Added some embedded graphics maintainers to Cc who might be interested
in this]
On Fri, Apr 20, 2012 at 11:02:02AM +0100, Dave Airlie wrote:
> On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer
> wrote:
> > This patch adds support for creating simple drm devices. The
> > basic idea of this patch is
* Dave Airlie wrote:
> I get the feeling the drm can just be a virtual platform device of
> some sort, then it reads the device tree and binds all the information
> on what crtc/encoders are available,
That's pretty much what I've come up with in the second round of Tegra DRM
patches. Basically
On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer wrote:
> This patch adds support for creating simple drm devices. The
> basic idea of this patch is that drm drivers using the sdrm layer
> no longer have to implement a full drm device but instead only
> register crtcs, encoders and connectors with
On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
This patch adds support for creating simple drm devices. The
basic idea of this patch is that drm drivers using the sdrm layer
no longer have to implement a full drm device but instead only
register crtcs, encoders and
* Dave Airlie wrote:
I get the feeling the drm can just be a virtual platform device of
some sort, then it reads the device tree and binds all the information
on what crtc/encoders are available,
That's pretty much what I've come up with in the second round of Tegra DRM
patches. Basically
[Added some embedded graphics maintainers to Cc who might be interested
in this]
On Fri, Apr 20, 2012 at 11:02:02AM +0100, Dave Airlie wrote:
On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
This patch adds support for creating simple drm devices. The
basic idea of
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
* Dave Airlie wrote:
I get the feeling the drm can just be a virtual platform device of
some sort, then it reads the device tree and binds all the information
on what crtc/encoders are available,
That's pretty much what I've
On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
(BTW each driver in drm has this layer somewhere in it. If I had hidden
it in imx specific functions I probably wouldn't have raised any
questions, but I don't want to go that way)
That's _exactly_ what you should be doing. And once
* Mark Brown wrote:
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
* Dave Airlie wrote:
I get the feeling the drm can just be a virtual platform device of
some sort, then it reads the device tree and binds all the information
on what crtc/encoders are available,
* Mark Brown wrote:
On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
* Mark Brown wrote:
This sounds an awful lot like how ASoC hangs together...
What in particular sounds awful?
Nothing - an awful is an English idiom for very.
I know =) But it has a somewhat
On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
* Dave Airlie wrote:
I get the feeling the drm can just be a virtual platform device of
some sort, then it reads the device tree and binds all the information
on
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
* Dave Airlie wrote:
I get the feeling the drm can just be a virtual platform device of
some sort, then it reads the device tree and binds all the information
on what crtc/encoders are available,
That's pretty much what I've
On Fri, Apr 20, 2012 at 05:15:18PM +0200, Sascha Hauer wrote:
On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:
This sounds an awful lot like how ASoC hangs together...
Very much, yes. In ASoC and DRM we both have several physical devices spread
around the SoC which form a logical
On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
* Mark Brown wrote:
This sounds an awful lot like how ASoC hangs together...
What in particular sounds awful?
Nothing - an awful is an English idiom for very.
signature.asc
Description: Digital signature
On Wed, Apr 11, 2012 at 09:22:47PM +0100, Alan Cox wrote:
> > +static int sdrm_suspend(struct drm_device *drm, pm_message_t state)
> > +{
> > + /* TODO */
> > +
> > + return 0;
> > +}
> > +
> > +static int sdrm_resume(struct drm_device *drm)
> > +{
> > + /* TODO */
> > +
> > + return 0;
>
On Wed, Apr 11, 2012 at 09:22:47PM +0100, Alan Cox wrote:
+static int sdrm_suspend(struct drm_device *drm, pm_message_t state)
+{
+ /* TODO */
+
+ return 0;
+}
+
+static int sdrm_resume(struct drm_device *drm)
+{
+ /* TODO */
+
+ return 0;
+}
These probably
> +static int sdrm_suspend(struct drm_device *drm, pm_message_t state)
> +{
> + /* TODO */
> +
> + return 0;
> +}
> +
> +static int sdrm_resume(struct drm_device *drm)
> +{
> + /* TODO */
> +
> + return 0;
> +}
These probably need to call into the sdrm device specific handling.
This patch adds support for creating simple drm devices. The
basic idea of this patch is that drm drivers using the sdrm layer
no longer have to implement a full drm device but instead only
register crtcs, encoders and connectors with the sdrm layer. The
sdrm layer then registers a drm device with
This patch adds support for creating simple drm devices. The
basic idea of this patch is that drm drivers using the sdrm layer
no longer have to implement a full drm device but instead only
register crtcs, encoders and connectors with the sdrm layer. The
sdrm layer then registers a drm device with
+static int sdrm_suspend(struct drm_device *drm, pm_message_t state)
+{
+ /* TODO */
+
+ return 0;
+}
+
+static int sdrm_resume(struct drm_device *drm)
+{
+ /* TODO */
+
+ return 0;
+}
These probably need to call into the sdrm device specific handling.
+static int
30 matches
Mail list logo
