From: Jesse Barnes <jbarnes@virtuousgeek.org> (by way of Jesse Barnes <jbarnes@virtuousgeek.org>)
To: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 01/11] drm: add plane support
Date: Tue, 25 Oct 2011 14:26:56 +0200 [thread overview]
Message-ID: <20111025142656.4b3aa405@jbarnes-x220> (raw)
In-Reply-To: <20111025115855.GC2894@phenom.ffwll.local>
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
> > Planes are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the
> > core KMS code.
> >
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>
> As discussed with Jesse on irc, drm fb handling is fragile. Current
> rules:
> - fbs are not reference counted, hence when destroying we need to
> disable all crtcs (and now also planes) that use them.
> drm_framebuffer_cleanup does that atm
> - drivers that hold onto fbs after the kms core drops the
> corresponding pointer needs to hold a ref onto the underlying backing
> storage (like e.g. for pageflip on the to-be-flipped-out fb as long
> as it might still be scanned out).
>
> We need proper refcounting for these ... But for now this patch is
> missing the plane cleanup in drm_framebuffer_cleanup.
Ah yeah that's a better place for the disable plane call I currently
have in the intel specific code... I'll fix up and test.
> Otherwise I think going with just the src and dst rect for set_plane
> is about the only sensible thing given the crazy hw out there. But I
> lack the knowledge about that kind of hw (and video stuff in
> general), so I'll refrain from slapping my r-b on these two.
Yeah, I think the drivers just need to be able to calculate the scaling
level from the params and program them into whatever regs they happen
to have (on Intel fortunately the scaling is figured out by hw when we
program in the source & dest values, subject to some restrictions).
Thanks,
Jesse
next prev parent reply other threads:[~2011-10-25 13:04 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 9:46 DRM planes and new fb creation ioctl Jesse Barnes
2011-10-25 9:46 ` [PATCH 01/11] drm: add plane support Jesse Barnes
2011-10-25 10:53 ` Joonyoung Shim
2011-10-25 11:18 ` Jesse Barnes
2011-10-26 0:19 ` Joonyoung Shim
2011-10-25 11:58 ` Daniel Vetter
2011-10-25 12:26 ` Jesse Barnes [this message]
2011-10-25 13:26 ` Alan Cox
2011-10-25 13:32 ` Jesse Barnes
2011-10-25 13:42 ` Daniel Vetter
2011-10-25 14:09 ` Jesse Barnes
2011-10-25 16:43 ` Rob Clark
2011-10-25 19:41 ` Daniel Vetter
2011-10-25 20:14 ` Rob Clark
2011-10-27 14:05 ` SW Kim
2011-10-31 11:40 ` Inki Dae
2011-10-31 16:52 ` Jesse Barnes
2011-11-02 2:20 ` Inki Dae
2011-11-02 15:57 ` Jesse Barnes
2011-10-26 5:40 ` Joonyoung Shim
2011-10-27 15:31 ` Jesse Barnes
2011-10-25 9:46 ` [PATCH 02/11] drm: add an fb creation ioctl that takes a pixel format Jesse Barnes
2011-10-25 9:46 ` [PATCH 03/11] drm/i915: rename existing overlay support to "legacy" Jesse Barnes
2011-10-25 9:46 ` [PATCH 04/11] drm/i915: add SNB video sprite support Jesse Barnes
2011-11-02 5:56 ` Inki Dae
2011-11-02 15:58 ` Jesse Barnes
2011-10-25 9:47 ` [PATCH 05/11] drm/i915: move pin & fence for plane past potential error paths Jesse Barnes
2011-10-25 9:47 ` [PATCH 06/11] drm/i915: plane teardown fixes Jesse Barnes
2011-10-25 9:47 ` [PATCH 07/11] drm/i915: enable new overlay code on IVB too Jesse Barnes
2011-10-25 9:47 ` [PATCH 08/11] drm/i915: overlay watermark hack Jesse Barnes
2011-10-25 9:47 ` [PATCH 09/11] drm/i915: fix overlay fb object handling Jesse Barnes
2011-10-25 9:47 ` [PATCH 10/11] drm/i915: clamp sprite to viewable area Jesse Barnes
2011-10-25 9:47 ` [PATCH 11/11] drm/i915: add sprite scaling support Jesse Barnes
2011-10-25 10:47 ` DRM planes and new fb creation ioctl Joonyoung Shim
2011-10-25 11:13 ` Jesse Barnes
2011-10-26 1:04 ` Joonyoung Shim
2011-10-25 11:20 ` Jesse Barnes
2011-10-25 11:22 ` [PATCH] drm/i915: add SNB video sprite support Jesse Barnes
2011-10-25 11:30 ` Jesse Barnes
2011-11-01 14:11 ` Lan, Hai
2011-11-03 18:44 ` [Intel-gfx] " Jesse Barnes
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=20111025142656.4b3aa405@jbarnes-x220 \
--to=jbarnes@virtuousgeek.org \
--cc=daniel@ffwll.ch \
/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