An error occurred fetching the project authors.
- 11 Nov, 2013 1 commit
-
-
Chon Ming Lee authored
vlv_dpio_read/write should be describe more in PHY centric instead of display controller centric. Create a enum dpio_channel for channel index and enum dpio_phy for PHY index. This should better to gather for upcoming platform. v2: Rebase the code based on drm/i915/vlv: Fix typo in the DPIO register define. v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro DPIO_PHY, and remove unrelated change. (Ville) Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 Nov, 2013 1 commit
-
-
Chon Ming Lee authored
Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current DPIO register definition doesn't have a structure way to break them down. As a result it is not easy to match the PHY/PLL registers with the configdb document. Rename those registers based on the configdb for easy cross references, and without the need to check the offset in the header file. New format is as following. <platform name>_<DPIO component><optional lane #>_DW<dword # in the doc>_<optional channel #> For example, VLV_PCS_DW0 - Group access to PCS for lane 0 to 3 for PCS DWORD 0. VLV_PCS01_DW0_CH0 - PCS access to lane 0/1, channel 0 for PCS DWORD 0. Another example is VLV_TX_DW0 - Group access to TX lane 0 to 3 for TX DWORD 0 VLV_TX0_DW0 - Refer to TX Lane 0 access only for TX DWORD 0. There is no functional change on this patch. v2: Rebase based on previous patch change. v3: There may be configdb different version that document the start DW differently. Add a comment to clarify. Fix up some mismatch start DW for second PLL block. (Ville) Suggested-by:
-
- 31 Oct, 2013 3 commits
-
-
Paulo Zanoni authored
That explains why I was seeing 2 consecutive "Turning eDP VDD off" messages. Regression introduced by: commit bf13e81b Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 6 07:40:05 2013 +0300 drm/i915: add support for per-pipe power sequencing on vlv Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Paulo Zanoni authored
Now we only print messages when we actually enable VDD and when we actually disable VDD. The changes in the last commit triggered a big number of messages while the driver was being initialized, and I thought we were toggling things on/off too many times, but that was not really true: we were just being too verbose. Signed-off-by:
-
Paulo Zanoni authored
If the eDP output is disabled, then we try to use /dev/i2c-X file to do i2c transations, we get a WARN from intel_dp_check_edp() saying we're trying to do AUX communication with the panel off. So this commit reorganizes the code so we enable the VDD at intel_dp_i2c_aux_ch() instead of just the callers inside i915.ko. This fixes the i2c subtest from the pc8 test of intel-gpu-tools on machines that have eDP panels. Signed-off-by:
-
- 28 Oct, 2013 1 commit
-
-
Jani Nikula authored
This isn't a real fix to the problem, but rather a stopgap measure while trying to find a proper solution. There are several laptops out there that fail to light up the eDP panel in UEFI boot mode. They seem to be mostly IVB machines, including but apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot. The difference between UEFI and CSM is that the BIOS provides a different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and 1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz link, and for reasons yet unknown fail to light up the panel. Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with 2.7 GHz link, the eDP panel lights up. So essentially this is a link speed issue, and *not* a bpp clamping issue. The bug raised its head since commit 657445fe Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat May 4 10:09:18 2013 +0200 Revert "drm/i915: revert eDP bpp clamping code changes" which started clamping bpp *before* computing the link requirements, and thus affecting the required bandwidth. Clamping after the computations kept the link at 2.7 GHz. Even though the BIOS tells us to use 18 bpp through the VBT, it happily boots up at 24 bpp and 2.7 GHz itself! Use this information to selectively ignore the VBT provided value. We can't ignore the VBT eDP bpp altogether, as there are other laptops that do require the clamping to be used due to EDID reporting higher bpp than the panel can support. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950Tested-by:
Ulf Winkelvos <ulf@winkelvos.de> Tested-by:
jkp <jkp@iki.fi> CC: stable@vger.kernel.org Signed-off-by:
-
- 18 Oct, 2013 1 commit
-
-
Jani Nikula authored
This is useful with the follow-up patch that frobs dev_priv->vbt.edp_bpp, and the value no longer comes directly from VBT. Signed-off-by:
-
- 15 Oct, 2013 1 commit
-
-
Jani Nikula authored
Follow-up to commit 0aec2881 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 27 19:01:01 2013 +0300 drm/dp: constify DP DPCD helpers Requested-by:
-
- 10 Oct, 2013 3 commits
-
-
Jani Nikula authored
The DP spec allows this, and requires it when full link training is started with non-minimum voltage swing and/or non-zero pre-emphasis. Signed-off-by:
-
Jani Nikula authored
If channel equalization succeeds, there's no indication something went wrong in clock recovery (unless debug is enabled). We should shout about the failures and fix them instead of hiding them under the carpet. This has allowed bugs like [1] stay dormant for a long time. [1] https://bugs.freedesktop.org/show_bug.cgi?id=70117Signed-off-by:
-
Jani Nikula authored
Signed-off-by:
-
- 09 Oct, 2013 2 commits
-
-
Jani Nikula authored
It's not really needed, rather just adds another place to hold intermediate values that could go wrong, and it's not clear that the training pattern set or training lane set should be written at this point at all. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Jani Nikula authored
v2: duplicate intel_connector->edid, not uninitialized edid (Dave Airlie). Signed-off-by:
-
- 03 Oct, 2013 2 commits
-
-
Rodrigo Vivi authored
for igt test case. v2: remove trailing spaces and fix conflicts Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: - make it comipile - s/IS_HASWELL/HAS_PSR/] Signed-off-by:
-
Rodrigo Vivi authored
Power Well in use forces constantly PSR to exit. On recent Kernel I noticed that PSR Performance Counter was always 0 indicating that PSR was never really achieved. By masking LPSP, PSR can work normally and save power on Haswell. Two bugs had been raised with PSR flag enabled: - "Screen flickers when booted by enabling PSR in the kernel (i915.enable_psr=1) , the system is booting to a gray screen." - "When booting the DUT with PSR feature enabled in the kernel (i915.enable_psr=1) , the system is booting to a gray screen." Both bugs has been fixed by this patch. v2: proper comment for -fixes Tested-by:
Selvaraj, Elavarasan <elavarasanx.selvaraj@intel.com> Signed-off-by:
-
- 01 Oct, 2013 10 commits
-
-
Paulo Zanoni authored
For some reason, every single time I try to run module_reload something tries to read the connector sysfs files. This happens after we destroy the encoders and before we destroy the connectors, so when the sysfs read triggers the connector detect() function, intel_conector->encoder points to memory that was already freed. The bad backtrace is just: [<ffffffff8163ca9a>] dump_stack+0x54/0x74 [<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915] [<ffffffffa001913d>] status_show+0x3d/0x80 [drm] [<ffffffff813d5340>] dev_attr_show+0x20/0x60 [<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0 [<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0 [<ffffffff811aaf1e>] vfs_read+0x9e/0x170 [<ffffffff811aba4c>] SyS_read+0x4c/0xa0 [<ffffffff8164e392>] system_call_fastpath+0x16/0x1b But if you add tons of memory checking debug options to your Kernel you'll also see: - general protection fault: 0000 - BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915] - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915] Among a bunch of other error messages. So this commit just destroys the sysfs files before both the encoder and connectors are freed. Signed-off-by: -
Jani Nikula authored
Neither the DP spec nor the compliance test spec state or imply that we should write the DP_TRAINING_PATTERN_SET at every voltage swing and pre-emphasis change. Indeed we probably shouldn't. So don't. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402Signed-off-by:
-
Jani Nikula authored
Per DP1.2 spec. Signed-off-by:
Todd Previte <tprevite@gmail.com> Signed-off-by:
-
Damien Lespiau authored
struct drm_mode_display now has a separate crtc_ version of the clock to be used when we're talking about the timings given to the harwadre (was far as the mode is concerned). This commit is really the result of a git grep adjusted_mode.*clock and replacing those by adjusted_mode.crtc_clock. No functional change. v2: Rebased on drm-intel-queued-next Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Acked-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Chon Ming Lee authored
Fix the typo in previous commit for DP 1.62 divisor. drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2 v2: sigh, the m1 div is 3. Reported-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ben Widawsky authored
Future generations will be changing these registers (thanks to design for giving us an early heads up). To help abstract, create the definition of the base of the register block, and define all registers relative to that. Design has promised to not change the offsets relative to the base. v2: Also change IS_HASWELL checks to HAS_PSR CC: Rodrigo Vivi <rodrigo.vivi@gmail.com> CC: Intel GFX <intel-gfx@lists.freedesktop.org> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Jani Nikula authored
Reduce AUX transactions for non-eDP. Signed-off-by:
-
Paulo Zanoni authored
We currently treat the child_device_config as a simple struct, but this is not correct: new BDB versions change the meaning of some offsets, so the struct needs to be adjusted for each version. Since there are too many changes (today we're in version 170!), making a big versioned union would be too complicated, so child_device_config is now a union of 3 things: (i) a "raw" byte array that's safe to use anywhere; (ii) an "old" structure that's the one we've been using and should be safe to keep in the SDVO and TV code; and (iii) a "common" structure that should contain only fields that are common for all the known VBT versions. Signed-off-by:
-
Daniel Vetter authored
Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by:
-
Jani Nikula authored
We haven't read the downstream port caps for DPCD 1.0, so don't use them. v2: use defines for DPCD 1.0 downstream port types Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
- 24 Sep, 2013 1 commit
-
-
Jani Nikula authored
There is no clear cut rules or specs for the retry interval, as there are many factors that affect overall response time. Increase the interval, and even more so on branch devices which may have limited i2c bit rates. Signed-off-by:
Nicolas Suzor <nic@suzor.com> Reviewed-by:
-
- 17 Sep, 2013 1 commit
-
-
Paulo Zanoni authored
So far we control everything and nothing exceeds the current limits, but (i) we never think about these limits when reviewing patches, (ii) not all the callers check the return values and (iii) if we ever hit any of these messages, we'll have to fix the code that added the bad message. The current limit for these messages is 20 since we only have 5 data registers on all the current gens. The checks inside intel_dp_aux_native_{write,read} are to prevent buffer overflows. The check inside intel_dp_aux_ch is to prevent writing past our 5 data registers. Signed-off-by:
-
- 16 Sep, 2013 3 commits
-
-
Ville Syrjälä authored
Move intel_crtc_active() to intel_display.c and make it available elsewhere as well. intel_edp_psr_match_conditions() already has one open coded copy, so replace that one with a call to intel_crtc_active(). v2: Copy paste a big comment from danvet's mail explaining when we can ditch the extra checks Signed-off-by: -
Ville Syrjälä authored
intel_edp_psr_match_conditions() currently looks at crtc->mode when it really needs to look at adjusted_mode. Fix it. Signed-off-by:
-
Ville Syrjälä authored
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we can kill the get_clock() callback and instead do the clock readout in get_pipe_config(). Also i9xx_crtc_clock_get() can now extract the frequency of the PCH DPLL, so use it to populate port_clock accurately for PCH encoders. For DP in port A the encoder is still responsible for filling in port_clock. The FDI adjusted_mode.clock extraction is kept in place for some extra sanity checking, but we no longer need to pretend it's also the port_clock. In the encoder get_config() functions fill out adjusted_mode.clock based on port_clock and other details such as the DP M/N values, HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then do an extra sanity check to make sure the dotclock we derived from the FDI configuratiuon matches the one we derive from port_clock. DVO doesn't exist on PCH platforms, so it doesn't need to anything but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so none of the changes apply there. v2: Use hdmi_reg color format to detect 12bpc HDMI case v3: Set adjusted_mode.clock for LVDS too v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get, eliminate the useless link_freq variable. Signed-off-by:
-
- 13 Sep, 2013 1 commit
-
-
Ville Syrjälä authored
Add functions to read out the CPU and PCH transcoder M/N values, and use them to fill out the pipe config dp_m_n information. And while at it populate has_dp_encoder too. Also refactor ironlake_get_fdi_m_n_config() to simply call the new intel_cpu_transcoder_get_m_n() function. v2: Remember the DDI Signed-off-by:
-
- 06 Sep, 2013 4 commits
-
-
Jani Nikula authored
VLV has per-pipe PP registers. Set up power sequencing on mode set. The connector init time setup is problematic, since we don't have a pipe at that time. Cook up something. v2: - use vlv_power_sequencer_pipe() also in _pp_{ctrl,stat}_reg() - use PANEL_PORT_SELECT_DPC_VLV (Ville) v3: make checkpatch happier Signed-off-by: -
Jani Nikula authored
Remove duplicates, add VLV specific macros for port B and C. v2: also add PANEL_PORT_SELECT_DPC_VLV for clarity (Ville) Signed-off-by:
-
Jani Nikula authored
Follow-up to commit 5004945f Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jul 30 12:20:32 2013 +0300 drm/i915: move encoder->enable callback later in VLV crtc enable v2: Rebase on the renamed enable hooks, adding clarity (Ville) Reference: http://mid.gmane.org/CAKMK7uFs9EMvMW8BnS24e5UNm1D7JrfVg3SD5SDFtVEamGfOOg@mail.gmail.comSigned-off-by:
-
Jani Nikula authored
In line with the rest of the code base. No functional changes. v2: also s/intel_pre_enable_dp/g4x_pre_enable_dp/ for consistency (Ville) Signed-off-by:
-
- 05 Sep, 2013 1 commit
-
-
Chon Ming Lee authored
The patch doesn't contain functional change, but is to prepare for future platform which has different DPIO phy. The additional pipe parameter will use to select which phy to target for. v2: Update the commit message and add static for the new function. (Jani/Ville) Signed-off-by:
-
- 04 Sep, 2013 2 commits
-
-
Chon Ming Lee authored
For DP pll settings, there is only two golden configs. Instead of running through the algorithm to determine it, hardcode the value and get it determine in intel_dp_set_clock. v2: Rework on the intel_limit compiler warning. (Jani) Signed-off-by:
-
Chon Ming Lee authored
eDP 1.4 supports 4-5 extra link rates in additional to current 2 link rate. Create a structure to store the DPLL divisor data to improve readability. v2: Fix the gen4_dpll/pch_dpll initialization to C99 designated initializers, and use a single loop for all platforms. (Jani and Daniel) Signed-off-by:
-
- 23 Aug, 2013 1 commit
-
-
Paulo Zanoni authored
This patch allows PC8+ states on Haswell. These states can only be reached when all the display outputs are disabled, and they allow some more power savings. The fact that the graphics device is allowing PC8+ doesn't mean that the machine will actually enter PC8+: all the other devices also need to allow PC8+. For now this option is disabled by default. You need i915.allow_pc8=1 if you want it. This patch adds a big comment inside i915_drv.h explaining how it works and how it tracks things. Read it. v2: (this is not really v2, many previous versions were already sent, but they had different names) - Use the new functions to enable/disable GTIMR and GEN6_PMIMR - Rename almost all variables and functions to names suggested by Chris - More WARNs on the IRQ handling code - Also disable PC8 when there's GPU work to do (thanks to Ben for the help on this), so apps can run caster - Enable PC8 on a delayed work function that is delayed for 5 seconds. This makes sure we only enable PC8+ if we're really idle - Make sure we're not in PC8+ when suspending v3: - WARN if IRQs are disabled on __wait_seqno - Replace some DRM_ERRORs with WARNs - Fix calls to restore GT and PM interrupts - Use intel_mark_busy instead of intel_ring_advance to disable PC8 v4: - Use the force_wake, Luke! v5: - Remove the "IIR is not zero" WARNs - Move the force_wake chunk to its own patch - Only restore what's missing from RC6, not everything Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 22 Aug, 2013 1 commit
-
-
Paulo Zanoni authored
Caught by "make W=1 drivers/gpu/drm/i915/". Signed-off-by:
-
