From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Kumar, Shobhit" <shobhit.kumar@intel.com>,
"akash.goel" <akash.goel@intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 6/6] drm/i915: New drm crtc property for varying the Crtc size
Date: Thu, 14 Aug 2014 21:51:27 +0300 [thread overview]
Message-ID: <20140814185127.GL4193@intel.com> (raw)
In-Reply-To: <CAKMK7uGPPbwhFOA39MwoQukWAMZYzUR0bCfKyEHJ5tAd6vvZyA@mail.gmail.com>
On Thu, Aug 14, 2014 at 08:33:23PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 7:58 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > Sure but the user can supply any mode, doesn't have to be on any list.
> > And the only sane rule for the frobbing would be that you can (slightly)
> > reduce hdisp/vdisp but never expand them so that there will never be any
> > extra garbage exposed (and the FB might not be big enough anyway). But
> > even reducing hdisp/vdisp by one pixel can be enough to anger the
> > hardware if a plane then extends one pixel into the blanking.
> >
> > This isn't much of a problem for i915 though. The hardware is generally
> > good enough to not need it. Double wide and (s)dvo/lvds gang mode are
> > the only exception that comes to mind. Even there we just need to make
> > pipe src width even, but still that's something we have to account
> > when clipping planes.
> >
> > On older hardware there were generally more restrictions eg. some
> > legacy baggage from VGA days which required horizontal timings to
> > be multiples of 8. I also "fondly" remember much more magic timing
> > restrictions in certain pieces hardware which were something close
> > to "if (foo*bar % this == that) frob else don't". IMO these kinds of
> > restrictions are too magic to make rejecting the mode an option,
> > so frobbing is the lesser of two evils.
>
> Imo the mode list we provide should be reasonable for everyone, and if
> you start to add your own modes then I expect the user to do that
> adjusting for us. Nowadays there should be very few cases where we
> don't provide decent mode lists and where it's not a super-special
> embedded thing where you need to configure everything yourself anyway.
> So I don't think we should ever adjust the input region for a crtc.
That's fine for decent hardware. But if/when I write a driver for
old junk I'm probably going to frob no matter what anyone says :)
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-08-14 18:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-14 9:24 [PATCH 0/6] New drm crtc property for varying the Crtc size akash.goel
2014-08-14 9:24 ` [PATCH 1/6] drm/i915: Added a return type for panel fitter config functions akash.goel
2014-08-14 9:24 ` [PATCH 2/6] drm/i915: Added a return type for the restore crtc mode function akash.goel
2014-08-14 9:24 ` [PATCH 3/6] drm/i915: Added Max down-scale ratio checks when enabling Panel fitter akash.goel
2014-08-14 9:24 ` [PATCH 4/6] drm/i915: Added support to allow change in FB pitch across flips akash.goel
2014-08-14 14:27 ` Daniel Vetter
2014-08-14 9:24 ` [PATCH 5/6] Documentation/drm: Describing crtc size property akash.goel
2014-08-14 9:24 ` [PATCH 6/6] drm/i915: New drm crtc property for varying the Crtc size akash.goel
2014-08-14 14:42 ` Daniel Vetter
2014-08-14 15:06 ` Ville Syrjälä
2014-08-14 15:26 ` Daniel Vetter
2014-08-14 15:32 ` Ville Syrjälä
2014-08-14 15:45 ` Ville Syrjälä
2014-08-14 16:07 ` Daniel Vetter
2014-08-14 16:45 ` Ville Syrjälä
2014-08-14 17:36 ` Daniel Vetter
2014-08-14 17:58 ` Ville Syrjälä
2014-08-14 18:33 ` Daniel Vetter
2014-08-14 18:51 ` Ville Syrjälä [this message]
2014-08-14 15:32 ` [PATCH 0/6] " Damien Lespiau
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=20140814185127.GL4193@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=akash.goel@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=shobhit.kumar@intel.com \
/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