- 21 May, 2015 1 commit
-
-
Chris Wilson authored
Our driver compiles clean (nowadays thanks to 0day) but for me, at least, it would be beneficial if the compiler threw an error rather than a warning when it found a piece of suspect code. (I use this to compile-check patch series and want to break on the first compiler error in order to fix the patch.) v2: Kick off a new "Debugging" submenu for i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jani Nikula <jani.nikula@intel.com> [danvet: Add "DRM i915" to the menu name as requested by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 May, 2015 39 commits
-
-
Damien Lespiau authored
The macros we use there are the magic ones that can take either dev or dev_priv. We'd like to move as much as possible towards dev_priv though. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Couldn't let it go! Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Currently bxt_resume_prepare() is only used in the runtime-resume path. Add it to the full S3/S4 path as well. v2: Rebase on top of the vlv_resume_prepare() shuffling around Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Sonika Jindal authored
Since DRM_ROTATE is counter clockwise (which is compliant with Xrandr), and HW rotation is clockwise, swapping 90/270 to work as expected from userspace. v2: Rebased Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ander Conselvan de Oliveira authored
Explain why a few fields of the new pipe_config have their values preserved, while the others are zeroed. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Also make the WA comment consistent with the rest, where the stepping info is not shown. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
ARGB8888 is used for cursors on all platforms so we need to allow it everywhere. ABGR8888 is currently only honoured: - on VLV/CHV in sprite planes - on SKL+ for primary and sprite planes so only allow it for those platforms. Note that we only support ARGB8888/ABGR8888 on the primary plane for SKL/BXT because we have in line of sight the pipe bottom color on those platforms and because the primary plane programming on VLV/CHV doesn't anything different for those formats today. v2: Fix the logic to forbid the creation ABGR2101010 fbs (Ville) v3: Still allow the creation of ARGB8888 fbs now that cursor planes use real fb objects (found by PRTS). Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Vandana Kannan authored
Making lane stagger calculation common for HDMI and DP v2: Imre's comments addressed - Remove lane stagger from bxt_clk_div and make it a local variable in ddi_pll_select Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Vandana Kannan authored
BUN 1: prop_coeff, int_coeff, tdctargetcnt programming updated and tied to VCO frequencies. Program i_lockthresh in PORT_PLL_9. VCO calculated based on the formula: Desired Output = Port bit rate in MHz (DisplayPort HBR2 is 5400 MHz) Fast Clock = Desired Output / 2 VCO = Fast Clock * P1 * P2 Prop_coeff, int_coeff, and tdctargetcnt modified according to above calculation. BUN 2: Port PLLs require additional programming at certain frequencies - DCO amplitude in PORT_PLL_10 Review comments from Siva which were addressed in the initial version of the patch. - Change PORT_PLL_LOCK_THRESHOLD to PORT_PLL_LOCK_THRESHOLD_MASK - Calculate for HDMI - Correct values for vco = 5.4 - return in case of invalid vco range v2: Imre's review comments addressed - change dcoampovr_en to dcoampovr_en_h - change PORT_PLL_DCO_AMP_OVR_EN to PORT_PLL_DCO_AMP_OVR_EN_H - Correct lane stagger value for 324MHz - Make coef common for HDMI and DP - remove superfluous comments v3: Imre's comments addressed - Remove Prop_coeff, int_coeff, tdctargetcnt, dcoampovr_en, gain_ctl, dcoampovr_en_h from bxt_clk_div and make them local variables. Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> [v1] Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Be in line with other features that we have. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Turn [drm:intel_dp_print_rates] source rates: 162000,270000,540000, [drm:intel_dp_print_rates] sink rates: 162000,270000, [drm:intel_dp_print_rates] common rates: 162000,270000, into [drm:intel_dp_print_rates] source rates: 162000, 270000, 540000 [drm:intel_dp_print_rates] sink rates: 162000, 270000 [drm:intel_dp_print_rates] common rates: 162000, 270000 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
We just have have VLV and CHV sprites programming the hardware differently for the ABGR2101010 so keep them working. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
That define makes it hard to figure out what is the actual list of formats at a glance. Expand it then. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Mika encountered one pathological scenario under X where acquiring all the mm locks (required to insert a mmu notifier) was very slow, so slow that by the time we tried to lock the struct_mutex with the usual call to i915_mutex_lock_interruptible(), X's signal timer had fired causing us to restart the ioctl (and so looped indefinitely). While I suspect this is the result of another bug (something leaking mm perhaps?) we can forgo the error checking and interuptible nature of the lock here so we only have to pay the expense once and get on with it. This does expose the userptr creation routine to a driver livelock though by not being interruptible. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Init ret to avoid issues reported by PRTS.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ander Conselvan de Oliveira authored
When the modeset code is reached with a CRTC that only needs a flip, the code that assigns PLLs is skipped. But since there is still a state swap for that CRTC, the current PLL assignment needs to be preserved. I missed the ddi_pll_sel field in the following commit, which causes warnings in DDI platforms. commit 4978cc93 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 21 17:13:21 2015 +0300 drm/i915: Preserve shared DPLL information in new pipe_config Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90410Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Tvrtko Ursulin authored
v2: Split strings to 80 char, add ddi_pll_sel and fixed typo. (Damien Lespiau) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ander Conselvan de Oliveira authored
In the following commit, the place where the contents of dpll_hw_state in crtc_state where zeroed was changed. Prior to that commit, it happened when the new state was allocated, but now that happens just before the call the .crtc_compute_clock() hook. The DP code for SKL, however, sets up the (private) PLL in the encoder compute config function that has already run by the time that memset() is reached, causing the previous value to be lost. This patch fixes the issue by moving the memset() down the call chain, so that it is only called if the values in dpll_hw_state are going to be updated. commit 4978cc93 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 21 17:13:21 2015 +0300 drm/i915: Preserve shared DPLL information in new pipe_config Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reported-and-tested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Add one explicit discard of __iomem address space qualifier in validate_vbt(), and respect it otherwise. This adds clarity in the code, and reduces the sparse warnings from the module to just one. Quoting Daniel, "The vbt really is plain old memory. Except that it's reserved in the e820 table as something special and hence treated as io range by the kernel. But it is memory, hence casting away the __iomem is imo the right approach." Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Tvrtko Ursulin authored
Just so it is grouped logically in line with other data and makes a rather verbose output a bit shorter. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chandra Konduru <chandra.konduru@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chandra Konduru <chandra.konduru@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Improve clarity. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
We never pass a non-NULL vbt to validate_vbt, and we can safely expect the callers to not change. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Ville noticed in another patch we we didn't need them at all, so remove them. It's worth saying that it makes no difference to code generated as gcc is clever enough to optimize it out. v2: Remove 'break' after 'return' in switches (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Currently DSI PLL N1 is hardcoded off. Make it possible to use it later. This should have no functional changes for now. v2: s/ffz(~(n))/ffs(n) - 1/ (Ville) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Animesh Manna authored
Added docbook info regarding context save and restore (CSR) firmware support added from gen9 onwards to drive newly added DMC (Display microcontroller) in display engine. v1: Initial version as RFC. v2: Used "DOC:" tag for csr description based on review comment from Daniel. Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Mika Kuoppala authored
Reading from disconnected ports will spit out timeout error on the dmesg. Skip the attempted read if the port is not connected and avoid confusing users/testcases about expected timeouts. This new dpcd debugfs entry was introduced by commit aa7471d2 ("drm/i915: add i915 specific connector debugfs file for DPCD") v2 by Jani: move the check at the top, out of the loop. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90060 Tested-by: yex.tian@intel.com Cc: Jani Nikula <jani.nikula@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Dan Carpenter authored
There is an extra semi-colon on the if statement so the debug output always says "Failed to write EDID checksum" even when it didn't fail. Fixes: 559be30c ('drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
We now prefix our functions/enums/data with the first platform it has been introduced. Do that for the primary plane formats. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: s/gen2/i8xx/ and s/gen4/i965/ ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
We advertize C8 in the primary plane formats didn't have the corresponding code to set PLANE_CTL accordingly. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Let's be consistent with the others skl_plane_ctl_*() functions and use a MISSING_CASE(). Not only that, but it's a rude to BUG() the whole machine here. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
No reason to not follow the 80 chars rule, renaming the local variable makes it easy. Cc: Chandra Konduru <chandra.konduru@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
We usually use a new line before those kind of return statements. Also the various skl_plane_ctl*() functions weren't consistent. Cc: Chandra Konduru <chandra.konduru@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Cc: Chandra Konduru <chandra.konduru@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Improve readability. No functional changes. v2: use more rational types (Ville) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Do not expose invalid gmbus pins as i2c devices to userspace. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-