From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/i915: retrieve current fb config into new plane_config structure at init v4
Date: Tue, 26 Nov 2013 10:11:23 -0800 [thread overview]
Message-ID: <20131126101123.20e2324a@jbarnes-desktop> (raw)
In-Reply-To: <20131126174353.GL27344@phenom.ffwll.local>
On Tue, 26 Nov 2013 18:43:53 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:
> > + plane_config->fb->base.pitches[0] =
> > + intel_framebuffer_pitch_for_width(dev_priv,
> > + plane_config->fb->base.width,
> > + plane_config->fb->base.bits_per_pixel,
> > + plane_config->tiled);
>
> Shouldn't we read out the stride from the respective hw register, too?
Hm that's quite an idea.
>
> > +
> > + plane_config->size = ALIGN(plane_config->fb->base.pitches[0] *
> > + plane_config->fb->base.height, PAGE_SIZE);
>
> If you bother with tiling I think you also need to bother with correct
> size alignement.
Yeah just fixed up the framebuffer size function per Ville's comments.
I should be able to just use that.
> > @@ -10562,6 +10672,7 @@ static void intel_init_display(struct drm_device *dev)
> > dev_priv->display.update_plane = ironlake_update_plane;
>
> Sad Haswell is sad it seems.
Yeah for two reasons: I'm not testing HSW at all, and I'm still fairly
ignorant of HSW display. Well that and I don't want to pile on more
work for this patchset which has already seen a bunch of churn...
> > + if (dev_priv->display.get_plane_config)
> > + dev_priv->display.get_plane_config(crtc,
> > + &crtc->plane_config);
> > + }
>
> If we go with Chris' suggestion to disable the crtc if we can't get at a
> sane framebuffer for it then this would make much more sense in the
> hardware state readout code. Especially since always having framebuffers
> around would allow us to ditch a bit of special-casing code all over the
> place.
I don't think so; reading out and allocating an fb on every plane
config readout would be overkill. We'd need to poke around in the
struct for cross checking, then free it somewhere. Plus it won't
always be preallocated, and creating a duplicate fb when the object
still exists would fail.
This is actually another argument for simply duplicating a few fields
from the fb struct into the plane config struct. That makes cross
checking and readout simple, and allows us to allocate if possible in
the BIOS functions.
But damnit, then I'd have to drop back to an earlier version of the
patch and lose some changes... ugg
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2013-11-26 18:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 23:51 [PATCH 1/5] drm/i915: make pitch_for_width take a tiled arg v2 Jesse Barnes
2013-11-25 23:51 ` [PATCH 2/5] drm/i915: split fb allocation and initialization v2 Jesse Barnes
2013-11-25 23:51 ` [PATCH 3/5] drm/i915: retrieve current fb config into new plane_config structure at init v4 Jesse Barnes
2013-11-26 13:57 ` Chris Wilson
2013-11-26 16:41 ` Jesse Barnes
2013-11-26 17:43 ` Daniel Vetter
2013-11-26 18:11 ` Jesse Barnes [this message]
2013-11-25 23:51 ` [PATCH 4/5] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7 Jesse Barnes
2013-11-26 14:09 ` Chris Wilson
2013-11-26 16:43 ` Jesse Barnes
2013-11-26 17:54 ` Daniel Vetter
2013-11-26 18:15 ` Jesse Barnes
2013-11-25 23:51 ` [PATCH 5/5] drm/i915: don't memset the fb buffer if preallocated Jesse Barnes
2013-11-26 14:13 ` Chris Wilson
2013-11-26 13:53 ` [PATCH 1/5] drm/i915: make pitch_for_width take a tiled arg v2 Chris Wilson
2013-11-26 17:28 ` Ville Syrjälä
2013-11-26 17:37 ` Jesse Barnes
2013-11-26 17:57 ` Daniel Vetter
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=20131126101123.20e2324a@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox