- 19 Nov, 2015 1 commit
-
-
Namrta Salonie authored
Found by static analysis tool. Signed-off-by:Namrta Salonie <namrta.salonie@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 Nov, 2015 33 commits
-
-
Imre Deak authored
MISSING_CASE() would have been useful to track down a recent problem in intel_display_port_aux_power_domain(), so add it there and a few related helpers. This was also suggested by Ville in his review of the latest DMC/DC changes, we forgot to address that. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447855045-7109-2-git-send-email-imre.deak@intel.com
-
Imre Deak authored
Due to the current sharing of the DDI encoder between DP and HDMI connectors we can run the DP detection after the HDMI detection has already set the shared encoder's type. For now solve this keeping the current behavior and running the detection in this case too. For a proper solution Ville suggested to split the encoder into an HDMI and DP one, that can be done as a follow-up. This issue triggers the WARN in intel_display_port_aux_power_domain() and was introduced in: commit 25f78f58 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Nov 16 15:01:04 2015 +0100 drm/i915: Clean up AUX power domain handling CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
Their logic is exactly the same: check if the digital port is connected and then call intel_dp_detect_dpcd(). So just put that logic in their only caller: intel_dp_detect(). Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
Ander Conselvan de Oliveira authored
That call was moved to intel_dp_detect() in commit d410b56d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 2 20:03:59 2014 +0100 drm/i915/dp: Refactor common eDP lid detection but it seem to have been resurrected in the following commit, probably due to a wrong merge conflict resolution. commit 2a592bec Author: Dave Airlie <airlied@redhat.com> Date: Mon Sep 1 16:58:12 2014 +1000 drm/i915: handle G45/GM45 pulse detection connected state. Signed-off-by:
-
Rodrigo Vivi authored
On the commit 3301d409 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic")' we already had identified that DP_PSR_NO_TRAIN_ON_EXIT doesn't mean we shouldn't send TPS patterns, however we start sending the minimal TP1 as possible and no TP2. For most of the panels this is ok, but we found a reported case where this is not true and panel keeps frozen without updating the screen for a while. We could just get this case after patch "PSR: Don't Skip aux handshake on DP_PSR_NO_TRAIN_ON_EXIT." is applied since that one fix the hard freeze on this kind of panels. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91436#c19 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:
-
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 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: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 6 commits
-
-
Patrik Jakobsson authored
Signed-off-by:
-
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:
-
