- 18 Nov, 2015 14 commits
-
-
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446839021-18599-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-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 26 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:
-
Imre Deak authored
When this option is 0 (so the power well support is disabled) we are supposed to enable all power wells once and don't disable them unless we system suspend the device. Currently if the option is 0, we can call the power well enable handlers multiple times, whenever their refcount changes from 0->1. This may not be a problem for the HW, but it's not logical and may trigger some warnings in the power well code which doesn't expect this. So simply keep around a reference while we are not system suspended to solve this. For simplicity mark the module option read only, so we don't need to deal with re-enabling the feature during runtime. If someone really needs that it could be added later in a more proper way. v2: - fix typo in comment in intel_power_domains_suspend() (Patrik) Signed-off-by:
-
Imre Deak authored
We don't need to reinit DDI and IRQs during PW1 enabling any more, since we don't toggle PW1 on-demand any more. We enable PW1 only as part of the display core init sequence and after this we initialize both DDI and IRQs later in the init sequence. So remove these init steps from the power well code. Signed-off-by:
-
Imre Deak authored
Suppressing LCPLL disabling was added to avoid interfering with the DMC firmware. It is not needed any more since we uninit CDCLK now with the DMC deactivated (DC states disabled). We also must disable it during system suspend as part of the Bspec "Display uninit sequence". Signed-off-by:
-
Imre Deak authored
We need to disable the DC states during display core init to sanitize the HW state we inherit from the BIOS. We need to disable it during display core uninit too, since the power well framework will leave it enabled (since we get to the display core uninit step with all power domains disabled already). Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
With the DMC firmware installed we don't need to handle HW resources that are handled automatically by the firmware. Besides being redundant this can also interfere with the firmware, possibly getting it into a broken/blocked state. The on-demand handling of PW1 was already half-way removed, MISC IO was still handled in this way. After the last patch we init/uninit these HW resources manually as part of the display core init/uninit sequence, so we can now remove the on-demand handling for these completely. We still keep around the power wells (with no domains attached to them) since the manual toggling during display core init/uninit happens via the current API. Signed-off-by:
-
Imre Deak authored
We need to initialize the display core part early, before initializing the rest of the display power state. This is also described in the bspec termed "Display initialization sequence". Atm we run this sequence during driver loading after power domain HW state initialization which is too late and during runtime suspend/resume which is unneeded and can interere with DMC functionality which handles HW resources toggled by this init/uninit sequence automatically. The init sequence must be run as the first step of HW power state initialization and during system resume. The uninit sequence must be run during system suspend. To address the above move the init sequence to the initial HW power state setup and the uninit sequence to a new power domains suspend function called during system suspend. As part of the init sequence we also have to reprogram the DMC firmware as it's lost across a system suspend/resume cycle. After this change CD clock initialization during driver loading will happen only later after other dependent HW/SW parts are initialized, while during system resume it will get initialized as the last step of the init sequence. This distinction can be removed by some refactoring of platform independent parts. I left this refactoring out from this series since I didn't want to change non-SKL parts. This is a TODO for later. v2: - fix error path in i915_drm_suspend_late() - don't try to re-program the DMC firmware if it failed to load Signed-off-by:
-
Imre Deak authored
Give a more proper name to this function. Signed-off-by:
-
Damien Lespiau authored
Before this patch, we used the intel_display_power_{get,put} functions to make sure the PW1 and Misc I/O power wells were enabled all the time while LCPLL was enabled. We called a get() at intel_ddi_pll_init() when we discovered that LCPLL was enabled, then we would call put/get at skl_{un,}init_cdclk(). The problem is that skl_uninit_cdclk() is indirectly called by intel_runtime_suspend(). So it will only release its power well _after_ we already decided to runtime suspend. But since we only decide to runtime suspend after all power wells and refcounts are released, that basically means we will never decide to runtime suspend. So what this patch does to fix that problem is move the PW1 + Misc I/O power well handling out of the runtime PM mechanism: instead of calling intel_display_power_{get_put} - functions that touch the refcount -, we'll call the low level intel_power_well_{en,dis}able, which don't change the refcount. This way, it is now possible for the refcount to actually reach zero, and we'll now start runtime suspending/resuming. v2 (from Paulo): - Write a commit message since the original patch left it empty. - Rebase after the intel_power_well_{en,dis}able rename. - Use lookup_power_well() instead of hardcoded indexes. Testcase: igt/pm_rpm/rte (and every other rpm test) Signed-off-by:Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Imre Deak authored
The current lookup code wouldn't find a power well if it's not in any power domain. There wasn't any power wells before but an upcoming patch will detach the power domains from power well#1 and the MISC IO power wells, so fix things up accordingly. Signed-off-by:
-
Imre Deak authored
lookup_power_well() expects uniq power well IDs, but atm we have uninitialized IDs which would clash with those power wells with a 0 ID. This wasn't a problem so far since nothing looked up such a power well, but an upcoming patch will (Misc IO for SKL), so fix this up on platforms where this matters. Signed-off-by:
-
Imre Deak authored
After fixing the same issue in the set_caching IOCTL and Chris' request to check out the possibilities for an improved RPM ref handling I noticed that we have the same issue in the set_tiling IOCTL. Fix this up.I didn't see any bug reports about this one, but the GTT unbind operation on this path accesses the HW, which needs the ref. Signed-off-by:
-
Chris Wilson authored
When accessing through the GTT from one CPU whilst concurrently updating the GGTT PTEs in another thread, the hardware likes to return random data. As we have strong serialisation prevent us from modifying the PTE of an active GTT mmapping, we have to conclude that it whilst modifying other PTE's that error occurs. (I have not looked for any pattern such as modifying PTE within the same page or cacheline as active PTE - though checking whether revoking neighbouring objects should be enough to test that theory.) The corruption also seems restricted to Braswell and disappears with maxcpus=0. This patch stops all access through the GTT by other CPUs when we update any PTE by stopping the machine around the GGTT update. Note that splitting up the 64 bit write into two 32 bit writes was tried and found to fail too. Testcase: igt/gem_concurrent_blit Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89079Signed-off-by:
-
Shubhangi Shrivastava authored
Compliance test 4.3.1.11 requires source to perform link training always if the automated test requests for it. This patch enforces this requirement. Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com Signed-off-by:
-
