We need to check eDP VDD force and panel on in several places, so
create some simple helper functions to avoid duplicating code.
Signed-off-by: Keith Packard <keithp@keithp.com>
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
From the eDP spec, we need the following numbers:
T1 + T3 Power on to Aux Channel operation (panel_power_up_delay)
This marks how long it takes the panel to boot up and
get ready to receive aux channel communications.
T8 Video signal to backlight on (backlight_on_delay)
Once a valid video signal is being sent to the device,
it can take a while before the panel is actuall
showing useful data. This delay allows the panel
to get something reasonable up before the backlight
is turned on.
T9 Backlight off to video off (backlight_off_delay)
Turning the backlight off can take a moment, so
this delay makes sure there is still valid video
data on the screen.
T10 Video off to power off (panel_power_down_delay)
Presumably this delay allows the panel to perform
an orderly shutdown of the display.
T11 + T12 Power off to power on (panel_power_cycle_delay)
So, once you turn the panel off, you have to wait a
while before you can turn it back on. This delay is
usually the longest in the entire sequence.
Neither the VBIOS source code nor the hardware documentation has a
clear mapping between the delay values they provide and those required
by the eDP spec. The VBIOS code actually uses two different labels for
the delay values in the five words of the relevant VBT table.
**** MORE LATER ***
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum of the two
delays, to make sure things work reliably. If there is no VBT data,
then those values will be initialized to zero, so we'll just use the
values as programmed in the hardware. Note that the BIOS just fetches
delays from the VBT table to place in the hardware registers, so we
should get the same values from both places, except for rounding.
VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.
The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.
The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.
For the backlight delays, the eDP spec says T6 + T8 is the delay from the
end of link training to backlight on and T9 is the delay from
backlight off until video off. The hardware provides a 'backlight on'
delay, which I'm taking to be T6 + T8 while the VBT provides something
called 'T7', which I'm assuming is s
On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.
Signed-off-by: Keith Packard <keithp@keithp.com>
Any call to intel_dp_sink_dpms must ensure that the panel has power so
that the DP_SET_POWER operation will be correctly received. The only
one missing this was in intel_dp_prepare.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The DP i2c initialization code does a couple of i2c transactions,
which means that an eDP panel must be powered up.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
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>
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>
Remove the duplicate "return" statement in drm_fb_helper_panic().
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv04/crtc: Bail out if FB is not bound to crtc
drm/nouveau: fix nv04_sgdma_bind on non-"4kB pages" archs
drm/nouveau: properly handle allocation failure in nouveau_sgdma_populate
drm/nouveau: fix oops on pre-semaphore hardware
drm/nv50/crtc: Bail out if FB is not bound to crtc
nv04_sgdma_bind binds the same page multiple times on
architectures where PAGE_SIZE != 4096.
Let's fix it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not cleaning after alloc failure would result in crash on destroy,
because nouveau_sgdma_clear assumes "ttm_alloced" to be not null when
"pages" is not null.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Keith Packard
Simon Farnsworth
Lin Ming
Dave Airlie
Emil Velikov
Marcin Slusarz
Ben Skeggs