- 18 Nov, 2015 28 commits
-
-
Rodrigo Vivi authored
Since the beginning there is a confusion on the meaning of this bit. A previous patch had identified this already and fixed it partially: 'commit 3301d409 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic") DP_PSR_NO_TRAIN_ON_EXIT means the source doesn't need to do the training, but it doesn't tell to avoid TP patterns or to skip aux handshake. This patch fixes the hard freeze reported. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91436 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91437 Cc: Ivan Mitev <ivan.mitev@gmail.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
With 'commit 30886c5a ("drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.")' we fixed a blank screen when first activation was happening immediately after PSR being enabled. There we gave more time for idleness by increasing the delay between re-activating sequences. However, commit "drm/i915: Delay first PSR activation." delay the first activation in a better way keeping a good PSR residency. So, we can now reduce the delay on re-enable. Signed-off-by:
-
Rodrigo Vivi authored
When debuging the frozen screen caused by HW tracking with low power state I noticed that if we keep moving the mouse non stop you will miss the screen updates for a while. At least until we stop moving the mouse for a small time and move again. The actual enabling should happen immediately after Display Port enabling sequence finished with links trained and everything enabled. However we face many issues when enabling PSR right after a modeset. On VLV/CHV we face blank screens on this scenario and on HSW+ we face a recoverable frozen screen, at least until next exit-activate sequence. Another workaround for the same issue here would be to increase re-enable idle time from 100 to 500 as we did for VLV/CHV. However this patch workaround this issue in a better way since it doesn't reduce PSR residency and also allow us to reduce the delay time between re-enables at least on VLV/CHV. This is also important to make the sysfs toggle working properly. Signed-off-by:
-
Ville Syrjälä authored
Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Add 'u32 offset' to the uncore register access functions. For now it's the same as 'reg', but once type safety gets added 'reg' will be the type safe register variable and 'offset' the raw offset. v2: s/uint32_t/u32/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
I need to add a new variable into GEN6_{READ,WRITE}_HEADER, but the vgpu won't need it, so let's avoid an unused variable warning by splitting the vgpu stuff to use its own macros. Cc: Eddie Dong <eddie.dong@intel.com> Cc: Jike Song <jike.song@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Yu Zhang <yu.c.zhang@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by:Zhiyuan Lv <zhiyuan.lv@intel.com>
-
Ville Syrjälä authored
We'll want to avoid performing arithmetic with register offsets, so instead calculating the vgpu PDP as pdp0_lo+offset, make the PDPs into an array. This way we can simply loop through them. Cc: Eddie Dong <eddie.dong@intel.com> Cc: Jike Song <jike.song@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Yu Zhang <yu.c.zhang@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We set up a load of LRIs in the logical ring context. Wrap that stuff in a macro to avoid typos with position of each reg/value pair in the context. This also makes it easier to make the register defines type safe. Signed-off-by:
-
Ville Syrjälä authored
The logical render context population has a bunch of raw ring register offsets. Use the names we have for them, and in cases where we we don't, give them names. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Add a helper for emitting register offsets (for LRI/SRM) into the w/a batch buffer. Signed-off-by:
-
Ville Syrjälä authored
When register type safety happens, we can't just try to emit the register itself to the ring. Instead we'll need to extract the offset from it first. Add some convenience functions that will do that. v2: Convert MOCS setup too Signed-off-by:
-
Ville Syrjälä authored
Add defines for the upper halves of the registers used by the cmd parser. Getting rid of the arithmetic with the register offset will help in making registers type safe. v2: s/_HI/_UDW/ (Chris) Signed-off-by:
-
Ville Syrjälä authored
Store the upper dword of the register offset in the whitelist as well. This would allow it to read register where the two halves aren't sitting right next to each other, and it'll make it easier to make register access type safe. While at it change the register offsets to u32 from u64. Our register space isn't quite that big, yet :) v2: Use ldw/udw as the suffixes, and add a note about 64bit wide split regs (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
Use the RING_PSMI_CTL define insted of hand rolling the register offset. Signed-off-by:
-
Ville Syrjälä authored
v2: Use for_each_ring() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Francisco Jerez <currojerez@riseup.net> Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Most of our register defines follow the convention that if there's a need for the raw register offset, that one has an underscore sa a prefix. The define (possibly parametrized) without the underscore is the one people should normally use, since it will take into account all the parameters and other potential offsets that are needed. Fix up the few stragglers that don't follow this convention. Signed-off-by:
-
Ville Syrjälä authored
If we ignore the BXT situation, we can observe that the only variables affecting gpio_mmio_base is IS_VALLEVIEW and HAS_GMCH_DISPLAY. The BXT situation we can fit into the same pattern if we change gmbus_pins_bxt[] to house the GMCH GPIO register offsets (like we do for all other platfotms). So let's do that. We could even simplify the VLV situation more by including the display_mmio_offset in the GPIO register defines, but let's leave it be for now. Signed-off-by:
-
Ville Syrjälä authored
Store the DVO SRCDIM register offset alongside the DVO control register offset in intel_dvo_device. This gets rid of the switch statement whose case values are the DVO control register offsets. Such a construct would cause problems for register type safety. Signed-off-by:
-
Ville Syrjälä authored
Replace the is_sdvob bool and some sdvo_reg checks with enum port. This makes the SDVO code look more modern, and gets rid of explicit register offset checks in the code which will hamper register type checking. v2: Add assert_sdvo_port_valid() (Chris) Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
i915 register defines are going to become type safe, so going forward the register defines can't be used as straight numbers. Since quirks.c needs just a few extra register defines from i915_reg.h, decouple the two by defining the required registers locally in quirks.c. This was already done for a few other igpu related registers. Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Rodrigo Vivi authored
Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
It was created at 'commit aabc95dc (drm/i915: Dont -ETIMEDOUT on identical new and previous (count, crc).")' becase the counter wasn't reliable. Now that we properly wait for the counter to be reset we can rely a bit more in the counter. Also that patch stopped to return -ETIMEDOUT so the test case is unable to skip when it is unreliable and end up in many fails that should be skip instead. So, with the counter more reliable we can remove this hack that just makes things more confusing when test cases are really expecting the same CRC and let test case skip if that's not the case. Signed-off-by:
-
Rodrigo Vivi authored
According to VESA DP spec TEST_CRC_COUNT (Bits 3:0) at TEST_SINK_MISC (00246h) is "Reset to 0 when TEST_SINK bit 0 = 0; So let's give few vblanks so we are really sure that this counter is really zeroed on the next sink_crc read. Signed-off-by:
-
Rodrigo Vivi authored
According to VESA DP Spec, setting TEST_SINK_START (bit 0) of TEST_SINK (00270h) "Stop/Start calculating CRC on the next frame" So let's wait at least 1 vblank to really say the calculation stopped or started. Signed-off-by:
-
- 17 Nov, 2015 12 commits
-
-
Patrik Jakobsson authored
Signed-off-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-13-git-send-email-patrik.jakobsson@linux.intel.com
-
Patrik Jakobsson authored
v2: Use _unsafe (Jani) v3: Allow specifying specific DC-states instead of just DC6 (Imre) Signed-off-by:
-
Patrik Jakobsson authored
Handle DC off as a power well where enabling the power well will prevent the DMC to enter selected DC states (required around modesets and Aux A). Disabling the power well will allow DC states again. For now the highest DC state is DC6 for Skylake and DC5 for Broxton but will be configurable for Skylake in a later patch. v2: Check both DC5 and DC6 bits in power well enabled function (Ville) v3: - Remove unneeded DC_OFF case in skl_set_power_well() (Imre) - Add PW2 dependency to DC_OFF (Imre) v4: Put DC_OFF before PW2 in BXT power well array Signed-off-by:
-
Patrik Jakobsson authored
v2: Add explanation of the fixed power well bits (Imre) Signed-off-by:
-
Patrik Jakobsson authored
PG2 enabled is not a requirement for disabling DC5. It's just one of the reasons why the DMC wouldn't enter DC5. During modeset we don't care about PG2 from a DC perspective, only the fact that DC5/DC6 is not allowed. Signed-off-by:
-
Patrik Jakobsson authored
We need a power domain for disabling DC5/DC6 around modesets to prevent confusing the DMC. Signed-off-by:
-
Patrik Jakobsson authored
We never make use of the distinction between 2 vs 4 lanes so combine them into a per port domain instead. This saves us a few bits in the power domain mask. Change suggested by Ville. Signed-off-by:
-
Ville Syrjälä authored
All the DDI power domains are already excluded from SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS on account of excluding SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS and SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS, no need to spell them out again. Signed-off-by:
-
Ville Syrjälä authored
Currently the gmbus code uses intel_aux_display_runtime_get/put in an effort to make sure the hardware is powered up sufficiently for gmbus. That function only takes the runtime PM reference which on VLV/CHV/BXT is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well 2 on BXT. So add a new power domnain for gmbus and kill off the now unused intel_aux_display_runtime_get/put. And change intel_hdmi_set_edid() to use the gmbus power domain too since that's all we need there. Also toss in a BUILD_BUG_ON() to catch problems if we run out of bits for power domains. We're already really close to the limit... [Patrik: Add gmbus string to debugfs output] Signed-off-by:
-
Ville Syrjälä authored
Introduce intel_display_port_aux_power_domain() which simply returns the appropriate AUX power domain for a specific port, and then replace the intel_display_port_power_domain() with calls to the new function in the DP code. As long as we're not actually enabling the port we don't need the lane power domains, and those are handled now purely from modeset_update_crtc_power_domains(). My initial motivation for this was to see if I could keep the DPIO power wells powered down while doing AUX on CHV, but turns out I can't so this doesn't change anything for CHV at least. But I think it's still a worthwile change. v2: Add case for PORT E. Default to POWER_DOMAIN_AUX_D for now. (Ville) Signed-off-by:
-
Patrik Jakobsson authored
Move call to gen9_set_dc_state_debugmask_memory_up() into gen9_set_dc_state() to prevent us missing it somewhere. Signed-off-by:
-
Patrik Jakobsson authored
Replaces "drm/i915: Force loading of csr program at boot" in the old series. Previously we called blindly into intel_csr_load_program() and depended on a check of whether the CSR program memory was cleared or not. This check is not reliable and no longer needed since we fixed the call-sites of intel_csr_load_program(). Signed-off-by:
-
