14 Jul, 2011
3 commits
-
opregion-based platforms will send ACPI video event 0x80 for a range of
notification types for legacy compatibility. This is interpreted as a
display switch event, which may not be appropriate in the circumstances.
When we receive such an event we should make sure that the platform is
genuinely requesting a display switch before passing that event through
to userspace.Signed-off-by: Matthew Garrett
Tested-by: Adam Jackson
Signed-off-by: Keith Packard -
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.Signed-off-by: Keith Packard
Tested-by: Yi Sun -
Signed-off-by: Keith Packard
Tested-by: Yi Sun
13 Jul, 2011
2 commits
-
...which is measured by the size and not the amount of space remaining.
Waiting upon size-8, did one of two things. In the common case with more
than 8 bytes available to write into the ring, it would return
immediately. Otherwise, it would timeout given the impossible condition
of waiting for more space than is available in the ring, leading to
warnings such as:[drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring
whilst cleaning up: -16Signed-off-by: Chris Wilson
Reviewed-by: Eric Anholt
Signed-off-by: Keith Packard
12 Jul, 2011
2 commits
-
This reverts commit a51f7a66fb5e4af5ec4286baef940d06594b59d2.
We still have a few Ironlake and Sandybridge machines which fail when
RC6 is enabled. Better luck next release?Signed-off-by: Keith Packard
-
i915_driver_load adds a write-combining MTRR region for the GTT
aperture to improve memory speeds through the aperture. If
i915_driver_load fails after this, it would not have cleaned up the
MTRR. This shouldn't cause any problems, except for consuming an MTRR
register. Still, it's best to clean up completely in the failure path,
which is easily done by calling mtrr_del if the mtrr was successfully
allocated.i915_driver_load calls i915_gem_load which register
i915_gem_inactive_shrink. If i915_driver_load fails after calling
i915_gem_load, the shrinker will be left registered. When called, it
will access freed memory and crash. The fix is to unregister the shrinker in the
failure path using code duplicated from i915_driver_unload.i915_driver_load also has some incorrect gotos in the error cleanup
paths:* After failing to initialize the GTT (which cannot happen, btw,
intel_gtt_get returns a fixed (non-NULL) value), it tries to
free the uninitialized WC IO mapping. Fixed this by changing the
target from out_iomapfree to out_rmmapSigned-off-by: Keith Packard
Tested-by: Lin Ming
09 Jul, 2011
9 commits
-
We'll try again with the new fixes. Prepare to see this reverted when
we get regression reports...Signed-off-by: Keith Packard
-
Upon review, all path share the same dependencies for updating the
registers and so we can benefit from sharing the code and checking
early.This removes the unsightly intel_wait_for_vblank() from the lowlevel
functions and upon further analysis the only path that will require a
wait is if we are performing an instantaneous transition between two
valid FBC configurations. The page-flip path itself will have disabled
FBC registers and will have waited for at least one vblank before
finishing the flip and attempting to re-enable FBC. This wait can be
accomplished simply by delaying the enable until after we are sure that
a vblank will have passed, which we are already doing to make sure that
the display is settled before enabling FBC.Signed-off-by: Chris Wilson
Reviewed-by: Keith Packard
Signed-off-by: Keith Packard -
In order to accommodate the requirements of re-enabling FBC after
page-flipping, but to avoid doing so and incurring the cost of a wait
for vblank in the middle of a page-flip sequence, we defer the actual
enablement by 50ms. If any request to disable FBC arrive within that
interval, the enablement is cancelled and we are saved from blocking on
the wait.Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard -
Page-flipping updates the scanout address, nukes the FBC compressed
image and so forces an FBC update so that the displayed image remains
consistent. However, page-flipping does not update the FBC registers
themselves, which remain pointing to both the old address and the old
CPU fence. Future updates to the new front-buffer (scanout) are then
undetected!This first approach to demonstrate the issue and highlight the fix,
simply disables FBC upon page-flip (a recompression will be forced on
every flip so FBC becomes immaterial) and then re-enables FBC in the
page-flip finish work function, so that the FBC registers are now
pointing to the new framebuffer and front-buffer rendering works once
more.Ideally, we want to only re-enable FBC after page-flipping is complete,
as otherwise we are just wasting cycles and power (with needless
recompression) whilst the page-flipping application is still running.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33487
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard -
Persistent mode is intended for use with front-buffer rendering, such as
X, where it is necessary to detect writes to the scanout either by the
GPU or through the CPU's fence, and recompress the dirty regions on the
fly. (By comparison to the back-buffer rendering, the scanout is always
recompressed after a page-flip.)References: https://bugs.freedesktop.org/show_bug.cgi?id=33487
References: https://bugs.freedesktop.org/show_bug.cgi?id=31742
Signed-off-by: Ben Widawsky
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard -
...and this requirement is enforced by intel_update_fbc() so we can
remove the later check from g4x_enable_fbc() and ironlake_enable_fbc().Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard -
The cfb_pitch was only used for 8xx_enable_fbc(), every later routine
was just overwriting the value with itself thanks to a copy'n'paste
error.Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard -
...to ensure that any pending FBC enable tasklet is cancelled.
Signed-off-by: Chris Wilson
Signed-off-by: Keith Packard -
As the enable/disable routines will be gain additional complexity in
future patches, it is necessary that all callers do not bypass the
generic interface by calling into the chipset routines directly. to do
this we make the chipset routines static, so there is no choice.Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard
08 Jul, 2011
20 commits
-
According to the hardware documentation, GDRST is exactly the same as on
Sandybridge. So simply enable the existing code.Signed-off-by: Kenneth Graunke
Signed-off-by: Keith Packard -
On sinks with a DPCD rev of 1.1 or greater, we can send sink power
management commands to address 0x600 per section 5.1.5 of the
DisplayPort 1.1a spec.Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
Signed-off-by: Keith Packard -
When checking link status during a hot plug event or detecting sink
presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a
DisplayPort spec). Consolidate the retry code into a
native_aux_read_retry function for use by get_link_status and _detect.Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
Signed-off-by: Keith Packard -
We currently use this when a hot plug event is received, only checking
the link status and re-training if we had previously configured a link.
However if we want to preserve the DP configuration across both hot plug
and DPMS events (which we do for userspace apps that don't respond to
hot plug uevents), we need to unconditionally check the link and try to
bring it up on hot plug.Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
Signed-off-by: Keith Packard -
If ->detect is called too soon after a hot plug event, the sink may not
be ready yet. So try up to 3 times with 1ms sleeps in between tries to
get the data (spec dictates that receivers must be ready to respond within
1ms and that sources should try 3 times).See section 9.1 of the 1.1a DisplayPort spec.
Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
Signed-off-by: Keith Packard -
When a hotplug event is received, we need to check the receiver cap bits
in case they've changed (as they might with a hub or chain config).Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
Signed-off-by: Keith Packard -
Makes it easier to search for DP related constants.
Reviewed-by: Keith Packard
Signed-off-by: Jesse Barnes
Signed-off-by: Keith Packard -
Especially after a hotplug or power status change, the sink may not
reply immediately to a link status query. So retry 3 times per the spec
to really make sure nothing is there.See section 9.1 of the 1.1a DisplayPort spec.
Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
Signed-off-by: Keith Packard -
Now that we track bpp on a per-pipe basis, we can use the actual value
rather than assuming 24bpp.Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
This will catch bad fb configs earlier.
Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
To properly drive a framebuffer with a new depth or bpp, dither settings
and link bandwidth calculations may change, so make sure we go through a
full mode set in that case.Reported-by: Chris Wilson
Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
The Intel HDMI encoder can support 8bpc or 12bpc. Set the appropriate
value based on the pipe bpp when configuring the output.Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
The pipe may be driving various bpp values depending on the display
configuration, so take that into account when calculating link bandwidth
requirements.Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
Updating the planes is device specific, so create a new display callback
and use it in pipe_set_base. (In fact we could go even further, valid
display plane bits have changed with each generation, as has tiled
buffer handling.)Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
Figuring out which pipe bpp to use is a bit painful. It depends on both
the encoder and display configuration attached to a pipe. For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
on the pipe but also enable dithering. But driving that same
framebuffer to a DisplayPort output on another pipe means using 8bpc and
no dithering.So split out and enhance the code to handle the various cases, returning
an appropriate pipe bpp as well as whether dithering should be enabled.Save the resulting pipe bpp in the intel_crtc struct for use by encoders
in calculating bandwidth requirements (defaults to 24bpp on pre-ILK).Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
This may not be the default value, so pull the bpc out of the pipe reg
and write it to the DP transcoder so proper dithering and signaling
occurs.Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
This prevents us from setting reserved or incorrect bits on CougarPoint.
Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard -
These bits are reserved on ILK+ (ILK+ provides this feature in the
transcoder and pipe configuration instead, which we already set).Signed-off-by: Jesse Barnes
Reviewed-by: Chris Wilson
Signed-off-by: Keith Packard
05 Jul, 2011
4 commits
-
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: (277 commits)
[SCSI] isci: fix checkpatch errors
isci: Device reset should request sas_phy_reset(phy, true)
isci: pare back error messsages
isci: cleanup silicon revision detection
isci: merge scu_unsolicited_frame.h into unsolicited_frame_control.h
isci: merge sata.[ch] into request.c
isci: kill 'get/set' macros
isci: retire scic_sds_ and scic_ prefixes
isci: unify isci_host and scic_sds_controller
isci: unify isci_remote_device and scic_sds_remote_device
isci: unify isci_port and scic_sds_port
isci: fix scic_sds_remote_device_terminate_requests
isci: unify isci_phy and scic_sds_phy
isci: unify isci_request and scic_sds_request
isci: rename / clean up scic_sds_stp_request
isci: preallocate requests
isci: combine request flags
isci: unify can_queue tracking on the tci_pool, uplevel tag assignment
isci: Terminate dev requests on FIS err bit rx in NCQ
isci: fix frame received locking
... -
* 'at91/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-2.6-arm-soc:
AT91: Change nand buswidth logic to match hardware default configuration
at91: Use "pclk" as con_id on at91cap9 and at91rm9200
at91: fix udc, ehci and mmc clock device name for cap9/9g45/9rl
atmel_serial: fix internal port num
at91: fix at91_set_serial_console: use platform device id -
…l/git/lethal/fbdev-3.x
* 'fbdev-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-3.x:
vesafb: fix memory leak
fbdev: amba: Link fb device to its parent
fsl-diu-fb: remove check for pixel clock ranges
udlfb: Correct sub-optimal resolution selection.
hecubafb: add module_put on error path in hecubafb_probe()
sm501fb: fix section mismatch warning
gx1fb: Fix section mismatch warnings
fbdev: sh_mobile_meram: Correct pointer check for YCbCr chroma plane
