Talking to the eDP DDC channel requires that the panel be powered
up. Wrap both the EDID and modes fetch code with calls to turn the vdd
power on and back off.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On eDP, DDC requires panel power, but turning that on uses the panel
power sequencing timing values fetch from the DPCD data.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the panel is already off, we'll need to turn VDD on to execute the
(useless) DPMS off code. Yes, it would be better to just not do any of
this, but correctness, and *then* performance.
Signed-off-by: Keith Packard <keithp@keithp.com>
The VDD force bit is turned on before touching the panel, but if it
was enabled, there was no call to turn it back off. Add a call.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard <keithp@keithp.com>
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard <keithp@keithp.com>
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This masks out all interrupts and ack's any pending ones at IRQ
uninstall time to make sure we don't receive any unexpected interrupts
later on.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The reference clock configuration must be done before any mode setting
can occur as all outputs must be disabled to change
anything. Initialize the clocks after turning everything off during
the initialization process.
Also, re-initialize the refclk at resume time.
Signed-off-by: Keith Packard <keithp@keithp.com>
I can't find any reference clocks which run at 96MHz as seems to be
indicated from the comments in this code.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
When trying to use SSC on Ibex Peak without CK505, any non-SSC outputs
(like VGA or TV) get broken. So, do not use SSC on Ibex Peak unless
there is a CK505 available (as specified by the VBT).
On Cougar Point, all clocking is internal, so SSC can always be used,
and there will never be a CK505 available.
This eliminates VGA shimmer on some Ironlake machines which have a
CK505 clock source.
References: https://bugzilla.kernel.org/show_bug.cgi?id=21742
References: https://bugs.freedesktop.org/show_bug.cgi?id=38750
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
The PCH refclk settings are global, so we need to look at all of the
encoders, not just the current encoder when deciding how to configure
it. Also, handle systems with more than one panel (any combination of
PCH/non-PCH eDP and LVDS).
Disable SSC clocks when no panels are connected.
Signed-off-by: Keith Packard <keithp@keithp.com>
Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This includes whether an eDP panel is present, and whether that should
use SSC (and at what frequency)
Signed-off-by: Keith Packard <keithp@keithp.com>
This tells the driver whether a CK505 clock source is available on
pre-PCH hardware. If so, it should be used as the non-SSC source,
leaving the internal clock for use as the SSC source.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wison <chris@chris-wilson.co.uk>
These are all KMS related anyways, so don't hide them under other
debug levels.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for Ironlake and older where it has been seen to
cause trouble with screen updates.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Francis Moreau <francis.moro@gmail.com>
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
Note that this is only tested on single-function DVI-D SDVOs, on two
platforms (965GME and 945GSE), and has not been checked against a
specification document.
With lots of help from Adam Jackson <ajax@redhat.com> on IRC.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
While I think the previous code is correct, it was hard to follow and
hard to debug. Since we already have a ring abstraction, might as well
use it to handle the semaphore updates and compares.
I don't expect this code to make semaphores better or worse, but you
never know...
v2:
Remove magic per Keith's suggestions.
Ran Daniel's gem_ring_sync_loop test on this.
v3:
Ignored one of Keith's suggestions.
v4:
Removed some bloat per Daniel's recommendation.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Test scheme: plug in the HDMI/DP monitor, and run
cat /proc/asound/card0/eld*
to check if the monitor name, HDMI/DP type, etc. show up correctly.
Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.
CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor.
This adds drm_edid_to_eld() for converting EDID to ELD. The converted
ELD will be saved in a new drm_connector.eld[128] data field. This is
necessary because the graphics driver will need to fixup some of the
data fields (eg. HDMI/DP connection type, AV sync delay) before writing
to the hardware ELD buffer. drm_av_sync_delay() will help the graphics
drivers dynamically compute the AV sync delay for fixing-up the ELD.
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be returned by drm_select_eld(). This policy may not be
suitable for all users, but let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor.
According to James, many TVs will either refuse the display anything or
pop-up an OSD warning whenever they receive hdmi audio which they cannot
handle. Eventually we will require configurability and/or per-monitor
audio control even when the video is cloned.
CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
CC: James Cloos <cloos@jhcloos.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We want to enable dithering on any pipe where the frame buffer has
more color resolution than the output device.
The previous code was incorrectly clamping the frame buffer bpc to the
display bpc, effectively disabling dithering all of the time as the
computed frame buffer bpc would never be larger than the display bpc.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6: (353 commits)
drm/nouveau: remove allocations from gart populate() hook
drm/nvc0/fb: slightly improve PMFB intr handling, move out of nvc0_graph.c
drm/nvc0/fifo: avoid touching missing subfifos
drm/nvd9/disp: bail out of mode_set_base if no fb bound to crtc
drm/nvd9/disp: stub some more api hooks so we don't oops on resume
drm/nouveau: fix printk typo in ioremap failure path
drm/nvc0/pm: minor clock readback fixes
drm/nv40/pm: execute memory reset script from vbios
drm/nv50/gr: refactor initialisation
drm/nouveau: if requested, try harder at disabling sysmem pushbufs
drm/nv50/gr: enable ctxprog xfer only when we need it to save power
drm/nouveau/dp: add support for displayport table 0x30
drm/nouveau/dp: return master dp table pointer too when looking up encoder
drm/nouveau/bios: simplify U/d table hash matching func to just match
drm/nouveau/dp: preserve non-pattern bits in DP_TRAINING_PATTERN_SET
drm/nvc0/gr: remove MODULE_FIRMWARE() lines
drm/nouveau/dp: use alternate lane mask for nvaf
drm/nouveau/dp: link rate scripts are selected with a comparison table
drm/nv40/pm: write nv40-specific reclocking routines
drm/nv40/pm: parse geometric delta clock from vbios
...
Since some somewhat questionable changes a while back, TTM provides a
completely empty array of struct dma_address that stays around for the
entire lifetime of the TTM object.
Lets use this array, *always*, rather than wasting yet more memory on
another array who's purpose is identical, as well as yet another bool array
of the same size saying *which* of the previous two arrays to use...
This change will also solve the high order allocation failures seen by
some people while using nouveau.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch adds instructions to ctxprog and by doing, impacts context
switching performance. My testcase showed a 1% performance cost using
glxgears that is a context-switch bound application.
Please test and report bugs/performance/power/other.
Many thanks to Maxim Levitsky for his dedicated work on lowering power
consumption with nouveau.
More patches are coming thanks to his work:
https://bugs.freedesktop.org/show_bug.cgi?id=37922
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Written from observations of my NVD9's vbios, completely untested due to
my NVD9 lacking actual DisplayPort connectors..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Will need to be able to distinguish 2.0/2.1 from 3.0 soon. Also, move
the vbios parsing to nouveau_dp where it belongs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We don't use these by default anymore, and there's been complaints from a
number of places thinking that the firmware blobs are required still.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not 100% perfect yet, but a good start towards what it'll look like in the
end.
Actually seems stable on a NV44 I have here, as much as running around OA
for a fair amount of time constantly switching between performance levels
can prove..
My NV49 isn't quite so happy, and semaphores mess up somehow (sometimes) as
a result of the memory reclocking.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This changes the meaning of what we reported as "core" clock previously.
The shader/rop units are allegedly supposed to be run at the base clock
listed in the perf table, while the geometric clock can be bumped from
this value on some boards.
So that we can report both, we'll report the base clock as "shader" (since
the shaders *do* run at it), and the geometric clock as "core".
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Keith Packard
Simon Farnsworth
Ben Widawsky
Wu Fengguang
Dave Airlie
Ben Skeggs
Marcin Slusarz
Martin Peres