- 22 9月, 2011 1 次提交
-
-
由 Keith Packard 提交于
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: NKeith Packard <keithp@keithp.com> Tested-by: NFrancis Moreau <francis.moro@gmail.com>
-
- 20 9月, 2011 1 次提交
-
-
由 Keith Packard 提交于
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: NKeith Packard <keithp@keithp.com> Reported-by: NOliver Hartkopp <socketcan@hartkopp.net> Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
-
- 26 8月, 2011 1 次提交
-
-
由 Thomas Jarosch 提交于
Otherwise it just contains random memory. Issue detected by cppcheck. Signed-off-by: NThomas Jarosch <thomas.jarosch@intra2net.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 23 8月, 2011 1 次提交
-
-
由 Kamal Mostafa 提交于
The commit "Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support" adds calls to intel_panel_setup_backlight() from intel_{lvds,dp}_init so do not call it again from intel_setup_outputs(). BugLink: http://bugs.launchpad.net/bugs/831542Signed-off-by: NKamal Mostafa <kamal@canonical.com> ACKed-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 10 8月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
We ought to be calling this from our DPMS routines as well as global state may change and we need to enable/disable clocks. So split out the code in preparation for further changes. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 09 8月, 2011 2 次提交
-
-
由 Keith Packard 提交于
Just an extra parameter which isn't actually needed. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Keith Packard 提交于
CPT pipe select is different from previous generations (using two bits instead of one). All of the paths from intel_disable_pch_ports were not making this distinction. Mode setting with pipe A turned off would then also force all outputs on pipe B to get turned off as the disable code would mistakenly decide that all of these outputs were on pipe A and turn them off. This is an extension of the CPT DP disable fix (why didn't I fix this then?) Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 02 8月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
The EDID parser will zero out the bpc value, and the driver needs to handle that case. In our picker, we'll just ignore 0 values as far as bpp picking goes. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39323. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 30 7月, 2011 3 次提交
-
-
由 Jesse Barnes 提交于
These bits moved around on SNB and above. v2: again with the git send-email fail v3: add macros for getting per-pipe override & enable bits v4: enable phase sync pointer on SNB and IVB configs as well Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Michel Alexandre Salim 提交于
Using the new quirk added to support disabling SSC on Lenovo U160 (#36656, commit 435793df), also register the Vaio as a special case and disable SSC for it. This patch fixes #34437 on fdo bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34437Signed-off-by: NMichel Alexandre Salim <salimma@fedoraproject.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
If a mode set fails we may get a message from drm_crtc_helper if we're lucky, but it won't tell us anything about *why* we failed to set a mode. So add a few DRM_ERRORs for the cases that shouldn't happen so we can debug things more easily. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 29 7月, 2011 6 次提交
-
-
由 Jesse Barnes 提交于
CB tuning is needed to handle potential process variations that might cause clock jitter for certain PLL settings. However, we were setting it incorrectly since we were using the wrong M value as a check (M1 when we needed to use the whole M value). Fix it up, making my HDMI attached display a little prettier (used to have occasional dots crawl across the display). Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Writes to the plane control register are buffered in the chip until a write to the DSPADDR (pre-965) or DSPSURF (post-965) register occurs. This patch adds flushes in: intel_enable_plane gen6_init_clock_gating ivybridge_init_clock_gating Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
After writing to the plane control reg we need to write to the surface reg to trigger the double buffered register latch. On previous chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg that triggers the double buffer latch. v2: write DSPADDR too to cover pre-965 chipsets v3: use flush_display_plane instead, that's what it's for v4: send the right patch Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
On CougarPoint and PantherPoint PCH chips, the timing generator may fail to start after DP training completes. This is due to a bug in the FDI autotraining detect logic (which will stall the timing generator and re-enable it once training completes), so disable it to avoid silent DP mode setting failures. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
This corrects the DPMS mode tracking so that the DPMS code will actually turn the CRTC off the next time the screen saves. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Keith Packard 提交于
Display port pipe selection on CPT is not done with a bit in the output register, rather it is controlled by a couple of bits in the separate transcoder register which indicate which display port output is connected to the transcoder. This patch replaces the simplistic macro DP_PIPE_ENABLED with the rather more complicated function dp_pipe_enabled which checks the output register to see if that is enabled, and then goes on to either check the output register pipe selection bit (on non-CPT) or the transcoder DP selection bits (on CPT). Before this patch, any time the mode of pipe A was changed, any display port outputs on pipe B would get disabled as intel_disable_pch_ports would ensure that the mode setting operation could occur on pipe A without interference from other outputs connected to that pch port Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAdam Jackson <ajax@redhat.com>
-
- 23 7月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
Per the specs and to address https://bugs.freedesktop.org/show_bug.cgi?id=36888. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 22 7月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
If a mode set fails we may get a message from drm_crtc_helper if we're lucky, but it won't tell us anything about *why* we failed to set a mode. So add a few DRM_ERRORs for the cases that shouldn't happen so we can debug things more easily. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 14 7月, 2011 1 次提交
-
-
由 Keith Packard 提交于
We've tried several times to make this machine 'just work', but every patch that does causes many other machines to fail. This adds a quirk which special cases this hardware and forces ssc to be disabled. There's no way to override this from the command line; that would be a significantly more invasive change. This patch fixes #36656 on fdo bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36656Signed-off-by: NKeith Packard <keithp@keithp.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=36656Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 09 7月, 2011 8 次提交
-
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
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=33487Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
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=31742Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
...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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
...to ensure that any pending FBC enable tasklet is cancelled. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 08 7月, 2011 5 次提交
-
-
由 Jesse Barnes 提交于
This will catch bad fb configs earlier. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
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: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
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: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
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: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
This prevents us from setting reserved or incorrect bits on CougarPoint. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 30 6月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
They use the same register interfaces, so we can simply enable the existing code on IVB. v2: - resolve conflict with ring freq scaling, we can enable it too v3: - resolve conflict again, this time on drm-intel-next Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 29 6月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
The ring frequency scaling table tells the PCU to treat certain GPU frequencies as if they were a given CPU frequency for purposes of scaling the ring frequency. Normally the PCU will scale the ring frequency based on the CPU P-state, but with the table present, it will also take the GPU frequency into account. The main downside of keeping the ring frequency high while the CPU is at a low frequency (or asleep altogether) is increased power consumption. But then if you're keeping your GPU busy, you probably want the extra performance. v2: - add units to debug table header (from Eric) - use tsc_khz as a fallback if the cpufreq driver doesn't give us a freq (from Chris) v3: - fix comments & debug output - remove unneeded force wake get/put Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Tested-by: NEric Anholt <eric@anholt.net> Reviewed-by: NEric Anholt <eric@anholt.net> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 27 6月, 2011 2 次提交
-
-
由 Jesse Barnes 提交于
Use the blit ring for submitting flips since the render ring doesn't generate flip complete interrupts. Fixes bugs: https://bugs.freedesktop.org/show_bug.cgi?id=38362 https://bugs.freedesktop.org/show_bug.cgi?id=38392 https://bugs.freedesktop.org/show_bug.cgi?id=38393Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NKenneth Graunke <kenneth@whitecape.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Tested-by: NJian J Zhao <jian.j.zhao@intel.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
This makes things a little clearer and prevents us from running old code on a new chipset that may not be supported. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewied-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 22 6月, 2011 1 次提交
-
-
由 Keith Packard 提交于
This change got placed in the ironlake path instead of the 9xx path during a recent code shuffle. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 10 6月, 2011 2 次提交
-
-
由 Chris Wilson 提交于
We need to perform a few operations in order to move the object into the display plane (where it can be accessed coherently by the display engine) that are important for future safety to forbid whilst pinned. As a result, we want to need to perform some of the operations before pinning, but some are required once we have been bound into the GTT. So combine the pinning performed by all the callers with set_to_display_plane(), so this complication is contained within the single function. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-