From: Daniel Vetter <daniel@ffwll.ch>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 0/8] lvds cleanup
Date: Tue, 20 Nov 2012 14:38:30 +0100 [thread overview]
Message-ID: <20121120133829.GH5854@phenom.ffwll.local> (raw)
In-Reply-To: <CA+gsUGQqPY62jKPGN21LVSOgN9c66HBTFCaUMf2PTLDu1K49eA@mail.gmail.com>
On Fri, Nov 16, 2012 at 02:09:05PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/11/5 Daniel Vetter <daniel.vetter@ffwll.ch>:
> > Hi all,
> >
> > This is the first cleanup from my next stab at reworking the modeset code, with
> > the ultimate goal that we can compute the entire configuration (fdi config, pll
> > config, sharing of global resources) up-front, before touching the hw at all.
> > Together with some neat hw state readout this should make fastboot much more
> > solid, and obviously it's a requirement to properly implement the check mode of
> > atomic modeset.
> >
> > Here I move some of the lvds stuff out of line, simple to better see through the
> > jungle. The newly-added pre_pll_enable callback might be unnecessary in the end,
> > since I think we should also move the pll enabling into the crtc_enable callback
> > and out of ->mode_set. Also, we need some notion of exclusive pch_pll (which the
> > lvds port needs to obey the modeset sequence) and stop disabling pch plls
> > unconditionally, since they might be in use by another active pipe. But that is
> > all stuff on top, once the entire clock handling rework settles.
> >
> > For context, my current wip (iow: where I am stuck atm ...):
> >
> > http://cgit.freedesktop.org/~danvet/drm/log/?h=modeset-rework
> >
> > Comments, flames and test reports highly welcome.
>
> Since you're already touching LVDS, can I also volunteer you to take a
> look at the LVDS_CTL register description on our documentation and
> implement all the workarounds listed there? A quick look shows we are
> missing at least bit 31 in cpt/ppt.
tbh I'm not sure what we're supposed to do with that w/a: Since the clock
gating bits need to be set until we first enable the lvds in dual_link
mode, I think this is the BIOS' job. So would you be ok if I just add a
check that those bits are set when enabling the lvds output. And if that's
not the case, print a debug message? We can think harder about this once
we have an lvds panel with a black screen ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2012-11-20 13:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 12:28 [PATCH 0/8] lvds cleanup Daniel Vetter
2012-11-05 12:28 ` [PATCH 1/8] drm/i915: add encoder->pre_pll_enable callback Daniel Vetter
2012-11-16 16:05 ` Paulo Zanoni
2012-11-16 16:21 ` Daniel Vetter
2012-11-16 16:59 ` Paulo Zanoni
2012-11-05 12:28 ` [PATCH 2/8] drm/i915: replace ad-hoc dual-link lvds checks Daniel Vetter
2012-11-16 16:37 ` Paulo Zanoni
2012-11-16 16:56 ` Daniel Vetter
2012-11-16 17:07 ` Paulo Zanoni
2012-11-16 17:17 ` Daniel Vetter
2012-11-05 12:28 ` [PATCH 3/8] drm/i915: move is_dual_link_lvds to intel_lvds.c Daniel Vetter
2012-11-16 17:18 ` Paulo Zanoni
2012-11-05 12:28 ` [PATCH 4/8] drm/i915: track is_dual_link in intel_lvds Daniel Vetter
2012-11-16 17:41 ` Paulo Zanoni
2012-11-05 12:28 ` [PATCH 5/8] drm/i915: add intel_lvds->reg Daniel Vetter
2012-11-16 17:46 ` Paulo Zanoni
2012-11-05 12:28 ` [PATCH 6/8] drm/i915: move intel_update_lvds to intel_lvds->pre_pll_enable Daniel Vetter
2012-11-16 18:07 ` Paulo Zanoni
2012-11-05 12:28 ` [PATCH 7/8] drm/i915: enable intel_lvds->pre_pll_enable for ilk+, too Daniel Vetter
2012-11-16 18:17 ` Paulo Zanoni
2012-11-05 12:28 ` [PATCH 8/8] drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set Daniel Vetter
2012-11-16 18:28 ` Paulo Zanoni
2012-11-16 18:33 ` Daniel Vetter
2012-11-16 16:09 ` [PATCH 0/8] lvds cleanup Paulo Zanoni
2012-11-20 13:38 ` Daniel Vetter [this message]
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=20121120133829.GH5854@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=przanoni@gmail.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