- 10 Oct, 2012 8 commits
-
-
Paulo Zanoni authored
Just set the only bit we need, everything else is either ignored on HDMI or should be set to zero. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Problems with the previous code: - HDMI just uses WRPLL1 for everything, so dual head cases might not work sometimes. - At encoder->mode_set we just write the PLL register without doing any kind of check (e.g., check if the PLL is already being used). - There is no way to fail and return error codes at encoder->mode_set. - We write to PORT_CLK_SEL at mode_set and we never disable it. - Machines hang due to wrong clock enable/disable sequence. So here we rewrite the code, making it a little more like the pre-Haswell PLL mode set code: - Check PLL availability at ironlake_crtc_mode_set. - Try to use both WRPLLs. - Check if PLLs are used before actually trying to use them, and properly fail with error messages. - Enable/disable PORT_CLK_SEL at the right place. - Add some WARNs to check for bugs. The next improvement will be to try to reuse PLLs if the timings match, but this is content for another patch and it's already documented with a TODO comment. Signed-off-by:Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Paulo Zanoni authored
It's a copy of ironlake_set_pipeconf with 2 differences: - There is no BPC field to set. - The interlaced mask is now 2 bits instead of 3. Signed-off-by:
-
Paulo Zanoni authored
On ironlake_crtc_mode_set, WARN if not using IBX or CPT. On haswell_crtc_mode_set, only run IBX/CPT code on IBX/CPT. I am still not sure whether IBX/CPT will be possible with a Haswell CPU, so leave the code there for now and put a WARN in case we spot it. Signed-off-by:
-
Paulo Zanoni authored
It's just a copy of ironlake_crtc_mode_set. Signed-off-by:
-
Paulo Zanoni authored
Previously we were enabling it at mode_set but never disabling. Let's follow the mode set sequence. Signed-off-by:
-
Paulo Zanoni authored
And the right time is exactly after/before changing PIPE_CONF. See the documentation about the mode set sequence. This code is not inside any encoder-specific callback because DDI_FUNC_CTL is part of the pipe, so it is used by all encoders. Signed-off-by:
-
Paulo Zanoni authored
Right now, we're trying to enable LCPLL at every mode set, but we're never disabling it. Also, we really don't want to be disabling LCPLL since it requires a very complex disable/enable sequence. This register should really be set by the BIOS and we shouldn't be touching it. Still, let's try to check its value and print some errors in case we find something wrong. We're also adding intel_ddi_get_cdclk_freq which will be used later in other places. Signed-off-by:
-
- 08 Oct, 2012 4 commits
-
-
Chris Wilson authored
By using round_jiffies() we can align the wakeup of our worker to the nearest second in order to batch wakeups and reduce system load, which is useful for unimportant coarse tasks like our retire_requests. v2: round_jiffies_relative() already returns the relative timeout value, so no need to incorrectly perform the subtraction twice. The timer interface still leaves the possibility for the value of jiffies to change be we program the timer. Suggested-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Arjan van de Ven <arjan@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
round_jiffies() aligns the wakeup time to the nearest second in order to batch wakeups and reduce system load, which is useful for unimportant coarse timers like our hangcheck. v2: round_jiffies_relative() returns the relative jiffie value, whereas we need the absolute value for the timer. Suggested-by:
-
Damien Lespiau authored
This workaround is only valid for IVB and VLV and the write triggers an error on HSW. Signed-off-by:
-
Damien Lespiau authored
For the next person that checks these kind of things, without having to dig up the register definition. Signed-off-by:
-
- 07 Oct, 2012 2 commits
-
-
Wei Yongjun authored
Remove duplicated include. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Damien Lespiau authored
There's is another register (a read only, so no harm done) at 0x42020 on Haswell GPUs. Let's just remove the write from the copy&paste that introduced haswell_init_clock_gating(). A note for the interested reader, it does seem we have a duplication of the 0x42020 register definition, hence the removal of 2 writes. That duplication could be the object of a later patch. Signed-off-by:
-
- 04 Oct, 2012 2 commits
-
-
Jesse Barnes authored
Workaround for a culling optimization. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: Also apply to haswell, spotted by Damien.] Reviewed-by:
-
Jesse Barnes authored
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250Signed-off-by:
-
- 02 Oct, 2012 2 commits
-
-
Daniel Vetter authored
I'm official fed up with the yelling and useless indirection. Let it burn! Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Paulo Zanoni authored
Version 2: call intel_set_pipe_timings from both i9xx_crtc_mode_set and ironlake_crtc_mode_set, instead of just ironlake, as requested by Daniel Vetter. The problem caused by calling this function from i9xx_crtc_mode_set too is that now on i9xx we write to PIPESRC before writing to DSPSIZE and DSPPOS. I could not find any evidence in our documentation that this won't work, and the docs actually say the pipe registers should be set before the plane registers. Version 3: don't remove pipeconf bits on i9xx_crtc_mode_set. Signed-off-by:
-
- 01 Oct, 2012 1 commit
-
-
Jani Nikula authored
Make it easier to track backlight set requests coming through ASLE instead of the driver's own backlight sysfs interface. We've had enough of backlight issues to warrant some extra debug logs in the area. Signed-off-by:
-
- 28 Sep, 2012 7 commits
-
-
Vijay Purushothaman authored
Fixed correct min, max vco limits and dip ctl reg Signed-off-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Gajanan Bhat authored
Eventhough Valleyview display block is derived from Cantiga, VLV supports eDP. So, added eDP checks in i9xx_crtc_mode_set path. v2: use different DPIO_DIVISOR values for VGA, DP and eDP v3: fix DPIO value calculation to use same values for all display interfaces v4: removed unconditional enabling of 6bpc dithering based on comments from Daniel & Jani Nikula. Also changed the display enabling order to force eDP detection first. Signed-off-by:
-
Vijay Purushothaman authored
In valleyview voltageswing, pre-emphasis and lane control registers can be programmed only through the h/w side band fabric. Cleaned up DPLL calculations for Valleyview to support multi display configurations. v2: Based on Daniel's feedbacak, moved crt hotplug detect work around as separate patch. Also moved i9xx_update_pll_dividers to i8xx_update_pll and i9xx_update_pll. Signed-off-by:
-
Vijay Purushothaman authored
m n tu register offset has changed in Valleyview. Also fixed DP limit frequencies. Signed-off-by:
-
Vijay Purushothaman authored
Added DPIO data lane register definitions for Valleyview Signed-off-by:
-
Vijay Purushothaman authored
Fixed SDVOB and SDVOC bit definitions for Valleyview. Signed-off-by:
-
Vijay Purushothaman authored
Set hrawclk to 200 MHz and aux divider clock to 100 MHz for Valleyview. This enables the aux transactions in Valleyview. Signed-off-by:
-
- 26 Sep, 2012 7 commits
-
-
Jesse Barnes authored
To match IVB. Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
-
Adam Jackson authored
Note with a comment anything newer than DP 1.1a. Obviously this needs some work still... Signed-off-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Adam Jackson authored
If there's no downstream device, DPCD success is good enough. If there's a hotplug-capable downstream device, count the number of connected sinks in DP_SINK_STATUS and return success if it's non-zero. Otherwise, probe DDC and report appropriately. v2: Check DP_SINK_STATUS instead of something unrelated to sink status. Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Adam Jackson authored
v2: Fix parenthesis mismatch, spotted by Jani Nikula Tested-by:
-
Adam Jackson authored
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP 1.2 for the MST bits. Tested-by:
-
Adam Jackson authored
Tested-by:
-
- 25 Sep, 2012 4 commits
-
-
Paulo Zanoni authored
The last patches moved a lot of code from ironlake_crtc_mode_set to sub-functions, so these variables became useless. You could get warnings by enabling -Wunused-but-set-variable. Signed-off-by:
-
Paulo Zanoni authored
Too many lines just to compute the value of a single variable, so move this to its own function. Signed-off-by:
-
Paulo Zanoni authored
The set_m_n code was spread all over the mode_set function. Version 2: Don't set the DP M/N registers on ironlake_set_m_n. Daniel Vetter has plans to add some encoder-specific callbacks. Also, on this version we don't change the order we're writing the registers, making the code change safer. Signed-off-by:
-
Paulo Zanoni authored
As noticed by Daniel Vetter, intel_pipe_choose_bpp_dither should already check for invalid bpp values and set a valid value, so remove the recheck inside ironlake_crtc_mode_set and also replace a "default" switch case inside ironlake_set_pipeconf with a BUG(). Signed-off-by:
-
- 24 Sep, 2012 3 commits
-
-
Daniel Vetter authored
Manual backmerge of -rc7 to resolve a silent conflict leading to compile failure in drivers/gpu/drm/i915/intel_hdmi.c. This is due to the bugfix in -rc7: commit b98b6016 Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 07:43:22 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug Since this code moved around a lot in -next git put that snippet at the wrong spot. I've tried to fix this by making the conflict explicit by merging a version for next with: commit 3cce574f Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 11:19:00 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally But that failed to solve the entire problem. To avoid pushing out further -nightly branch to our QA where this is broken, do the backmerge and manually add the stuff git adds to -next from the patch in -fixes. Note that this doesn't show up in git's merge diff (and hence is also not handled by git rerere), which adds to the reasons why I'd like to fix this with a verbose backmerge. The git merge diff only shows a bunch of trivial conflicts of the "code changed in lines next to each another" kind. Signed-off-by:
-
Paulo Zanoni authored
This should never happen, but the silent "return" makes me wonder every time I try to debug InfoFrame bugs, so promote this to BUG() to make sure people will complain if we ever break this. Signed-off-by:
-
Linus Torvalds authored
-
