All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel@ffwll.ch (Daniel Vetter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/7] DRM: add sdrm layer for general embedded system support
Date: Fri, 20 Apr 2012 15:33:14 +0200	[thread overview]
Message-ID: <20120420133314.GF4217@phenom.ffwll.local> (raw)
In-Reply-To: <20120420131005.GO3852@pengutronix.de>

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 you have more than one
driver that works in a similar way, you can extract the common code as
helper functions to make life easier. Like Rob&Alan did with a few gem
helpers they needed in omapdrm/gma500.

For your case it sounds like a new set of modeset helper functions
tailored for the embedded use-case would be good (as Dave Airlie
suggested). Adding yet another middle-layer (like sdrm is) that forces
drivers to go through it usually ends up in tears. And drm core
unfortunately still has too much middle-layer heritage: For an awful lot
of setup and teardown issues it's the core of the problme - because
drivers can't control when drm sets up and tears down certain things, it's
done at the wrong time (for certain drivers at least). Same problem when
the abstraction doesn't quite fit.

Helper functions leave the driver in full control of what's going on, and
working around hw-specific madness with ease.

https://lwn.net/Articles/336262/ is the canonical reference for why a lot
of kernel people are allergic to anything that looks like a middle-layer.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
	dri-devel@lists.freedesktop.org, Rob Clark <rob.clark@linaro.org>
Subject: Re: [PATCH 3/7] DRM: add sdrm layer for general embedded system support
Date: Fri, 20 Apr 2012 15:33:14 +0200	[thread overview]
Message-ID: <20120420133314.GF4217@phenom.ffwll.local> (raw)
In-Reply-To: <20120420131005.GO3852@pengutronix.de>

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 you have more than one
driver that works in a similar way, you can extract the common code as
helper functions to make life easier. Like Rob&Alan did with a few gem
helpers they needed in omapdrm/gma500.

For your case it sounds like a new set of modeset helper functions
tailored for the embedded use-case would be good (as Dave Airlie
suggested). Adding yet another middle-layer (like sdrm is) that forces
drivers to go through it usually ends up in tears. And drm core
unfortunately still has too much middle-layer heritage: For an awful lot
of setup and teardown issues it's the core of the problme - because
drivers can't control when drm sets up and tears down certain things, it's
done at the wrong time (for certain drivers at least). Same problem when
the abstraction doesn't quite fit.

Helper functions leave the driver in full control of what's going on, and
working around hw-specific madness with ease.

https://lwn.net/Articles/336262/ is the canonical reference for why a lot
of kernel people are allergic to anything that looks like a middle-layer.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-04-20 13:33 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 15:33 [RFC] DRM helpers for embedded systems Sascha Hauer
2012-04-11 15:33 ` Sascha Hauer
2012-04-11 15:33 ` [PATCH 1/7] drm: remove legacy mode_group handling Sascha Hauer
2012-04-11 15:33   ` Sascha Hauer
2012-04-11 15:33 ` [PATCH 2/7] drm: make gamma_set optional Sascha Hauer
2012-04-11 15:33   ` Sascha Hauer
2012-04-11 15:33 ` [PATCH 3/7] DRM: add sdrm layer for general embedded system support Sascha Hauer
2012-04-11 15:33   ` Sascha Hauer
2012-04-11 20:22   ` Alan Cox
2012-04-11 20:22     ` Alan Cox
2012-04-12  8:58     ` Sascha Hauer
2012-04-12  8:58       ` Sascha Hauer
2012-04-20 10:02   ` Dave Airlie
2012-04-20 10:02     ` Dave Airlie
2012-04-20 12:38     ` Thierry Reding
2012-04-20 12:38       ` Thierry Reding
2012-04-20 13:20       ` Sascha Hauer
2012-04-20 13:20         ` Sascha Hauer
2012-04-20 14:25       ` Mark Brown
2012-04-20 14:25         ` Mark Brown
2012-04-20 14:49         ` Thierry Reding
2012-04-20 14:49           ` Thierry Reding
2012-04-20 15:06           ` Mark Brown
2012-04-20 15:06             ` Mark Brown
2012-04-20 15:13             ` Thierry Reding
2012-04-20 15:13               ` Thierry Reding
2012-04-20 15:15         ` Sascha Hauer
2012-04-20 15:15           ` Sascha Hauer
2012-04-20 15:20           ` Mark Brown
2012-04-20 15:20             ` Mark Brown
2012-04-20 13:10     ` Sascha Hauer
2012-04-20 13:10       ` Sascha Hauer
2012-04-20 13:33       ` Daniel Vetter [this message]
2012-04-20 13:33         ` Daniel Vetter
2012-04-21  8:18         ` Sascha Hauer
2012-04-21  8:18           ` Sascha Hauer
2012-04-11 15:33 ` [PATCH 4/7] DRM: Add sdrm 1:1 encoder - connector helper Sascha Hauer
2012-04-11 15:33   ` Sascha Hauer
2012-04-11 15:33 ` [PATCH 5/7] DRM: add i.MX kms simple driver Sascha Hauer
2012-04-11 15:33   ` Sascha Hauer
2012-04-11 15:33 ` [PATCH 6/7] ARM i.MX27 pcm038: Add sdrm support Sascha Hauer
2012-04-11 15:33   ` Sascha Hauer
2012-04-11 15:33 ` [PATCH 7/7] DRM: add PXA kms simple driver Sascha Hauer
2012-04-11 15:33   ` Sascha Hauer

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=20120420133314.GF4217@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.